Loading...
niagara avatar niagara 22 Точки

C++ Advanced 01. Pointers and References - Homework - Task 5 - Memory

Здравейте, при решаването на горепосочената задача забелязах, че в class Company няма методи за достъп до обектите и не можем да извършим операция от рода на Company c;  c.id =..., понеже обектите в класа са private. Въпросът ми е дали умишлено е пропусната възможността да достъпим обект по този начин (c.id =...), за да помислим за по-хитро решение или има някъде грешка?

0
C++ Programming 06/09/2018 11:53:13
georgi.stef.georgiev avatar georgi.stef.georgiev 921 Точки
Best Answer

Здравей,

Да, това е нарочно - не е толкова хитрост, колкото е изискване да се ползва конструктора на обекта, а не да се работи директно с полетата му. Съответно от вас се очаква да инициализирате локални променливи, които съответстват на полетата на конструктора, и когато сте готови с попълването на локалните променливи да извикате конструктора с тях.

Това се базира на следната идея:

В обектно-ориентираното програмиране имаме принципа на енкапсулацията - класовете си имат техни скрити полета, за които се грижат да са в правилна форма, и дават на външния код да работи с обекти от класа само през неща като конструктори и публични методи. Ако не беше така, класът няма как да гарантира, че са му правилно инициализирани полетата (примерно един vector няма как да гарантира, че ако size-ът му е 10, то тогава наистина има 10 елемента в паметта си, ако можеше външен код директно да достъпва size полето).

В нашия пример класът Company e сравнително прост и не прави някакви сериозни проверки при създаване, но пак е добра практика да си защитава полетата, защото ако след време решим да го променим - примерно ако решим да ползваме list вместо vector като поле, или пък нормален масив - то външния код, които ползва Company, ще продължи да си работи без да трябва да се променя, защото Company би си променил само вътрешните полета, но би оставил публичните си членове същите, като би правил някакви преобразувания за да попълни правилно вътрешните полета от конструктора си.

Тук всъщност имаме и още един принцип - когато един клас има конструктор, но няма setter-и, това показва, че след като един обект от него е създаден, той е "константен" - тоест гарантираме, че обектът никога няма да се промени от действия върху него. За Company това не е толкова релевантно (в реалния живот компанията може да си променя работниците примерно), но ако имахме клас Дистанционно, то веднъж след като едно дистанционно е създадено, не би трябвало ползването му да му променя състоянието (примерно да му падат бутони, или да му се сменят платките вътре) - липсата на setter-и гарантира това непроменяне на състоянието (или поне на състоянието наблюдавано отвън, класът пак може вътрешно да прави каквото си иска).

Поздрави,

Жоро

 

1
Можем ли да използваме бисквитки?
Ние използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Можете да се съгласите с всички или част от тях.
Назад
Функционални
Използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Използваме „сесийни“ бисквитки, за да Ви идентифицираме временно. Те се пазят само по време на активната употреба на услугите ни. След излизане от приложението, затваряне на браузъра или мобилното устройство, данните се трият. Използваме бисквитки, за да предоставим опцията „Запомни Ме“, която Ви позволява да използвате нашите услуги без да предоставяте потребителско име и парола. Допълнително е възможно да използваме бисквитки за да съхраняваме различни малки настройки, като избор на езика, позиции на менюта и персонализирано съдържание. Използваме бисквитки и за измерване на маркетинговите ни усилия.
Рекламни
Използваме бисквитки, за да измерваме маркетинг ефективността ни, броене на посещения, както и за проследяването дали дадено електронно писмо е било отворено.