Здравейте, при решаването на горепосочената задача забелязах, че в class Company няма методи за достъп до обектите и не можем да извършим операция от рода на Company c; c.id =..., понеже обектите в класа са private. Въпросът ми е дали умишлено е пропусната възможността да достъпим обект по този начин (c.id =...), за да помислим за по-хитро решение или има някъде грешка?
Здравей,
Да, това е нарочно - не е толкова хитрост, колкото е изискване да се ползва конструктора на обекта, а не да се работи директно с полетата му. Съответно от вас се очаква да инициализирате локални променливи, които съответстват на полетата на конструктора, и когато сте готови с попълването на локалните променливи да извикате конструктора с тях.
Това се базира на следната идея:
В обектно-ориентираното програмиране имаме принципа на енкапсулацията - класовете си имат техни скрити полета, за които се грижат да са в правилна форма, и дават на външния код да работи с обекти от класа само през неща като конструктори и публични методи. Ако не беше така, класът няма как да гарантира, че са му правилно инициализирани полетата (примерно един vector няма как да гарантира, че ако size-ът му е 10, то тогава наистина има 10 елемента в паметта си, ако можеше външен код директно да достъпва size полето).
В нашия пример класът Company e сравнително прост и не прави някакви сериозни проверки при създаване, но пак е добра практика да си защитава полетата, защото ако след време решим да го променим - примерно ако решим да ползваме list вместо vector като поле, или пък нормален масив - то външния код, които ползва Company, ще продължи да си работи без да трябва да се променя, защото Company би си променил само вътрешните полета, но би оставил публичните си членове същите, като би правил някакви преобразувания за да попълни правилно вътрешните полета от конструктора си.
Тук всъщност имаме и още един принцип - когато един клас има конструктор, но няма setter-и, това показва, че след като един обект от него е създаден, той е "константен" - тоест гарантираме, че обектът никога няма да се промени от действия върху него. За Company това не е толкова релевантно (в реалния живот компанията може да си променя работниците примерно), но ако имахме клас Дистанционно, то веднъж след като едно дистанционно е създадено, не би трябвало ползването му да му променя състоянието (примерно да му падат бутони, или да му се сменят платките вътре) - липсата на setter-и гарантира това непроменяне на състоянието (или поне на състоянието наблюдавано отвън, класът пак може вътрешно да прави каквото си иска).
Поздрави,
Жоро