У чому полягає асоціація, агрегація та склад?

Я пережив багато теорій про те, що таке інкапсуляція та три методики її здійснення, які є асоціація, агрегація та склад.

Я знайшов :

Інкапсуляція

Інкапсуляція - це техніка зробити поля в класі приватними та забезпечити доступ до полів відкритими методами. Якщо поле оголошено приватним, до нього не може отримати доступ хтось поза класом, тим самим приховуючи поля всередині класу. З цієї причини інкапсуляцію також називають приховуванням даних.

Інкапсуляція може бути описана як захисний бар'єр, який запобігає випадковому доступу до коду та даних іншим кодом, визначеним поза класом. Доступ до даних та коду жорстко контролюється інтерфейсом.

Основна перевага інкапсуляції - це можливість змінювати наш реалізований код, не порушуючи код інших, хто використовує наш код. Завдяки цій функції інкапсуляція забезпечує ремонтопридатність, гнучкість та розширюваність нашого коду.

Асоціація

Асоціація - це відносини, коли всі об'єкти мають свій життєвий цикл і немає власника. Візьмемо приклад вчителя та учня. Кілька учнів можуть асоціюватися з одним вчителем, а один студент може зв’язатися з декількома вчителями, але між об'єктами немає власності і обидва мають свій життєвий цикл. Обидва можуть створювати та видаляти самостійно.

Агрегація

Агрегація - це спеціалізована форма об'єднання, де всі об'єкти мають власний життєвий цикл, але існує право власності, і дочірній об’єкт не може належати іншому батьківському об'єкту. Візьмемо приклад кафедри та викладача. Один вчитель не може належати до декількох кафедр, але якщо ми видалимо кафедру, об'єкт викладача не буде знищений. Ми можемо думати про це як про відносини "має".

Склад

Склад - це знову спеціалізована форма агрегації, і ми можемо назвати це відносинами "смерті". Це сильний тип Агрегації. Дочірній об’єкт не має свого життєвого циклу, і якщо батьківський об’єкт видаляє всі дочірні об’єкти, він також буде видалений. Візьмемо ще раз приклад стосунків між будинком та кімнатами. Будинок може містити кілька номерів, але немає самостійного життя кімнати, і жодна кімната не може належати до двох різних будинків. Якщо ми видалимо будинок, кімната автоматично буде видалена.

Питання:

Тепер це все приклади реального світу. Я шукаю деякий опис про те, як використовувати ці методи в фактичному коді класу. Я маю на увазі, в чому сенс використання трьох різних технік інкапсуляції , як ці методи можна було б реалізувати та як вибрати, яку техніку застосувати в даний момент.

Різниця між асоціацією, агрегацією та складом, як ви описуєте це, є спадщиною, що повертається до старих часів ручного управління пам'яттю. Наприклад, на C ++ пам'ять, яку використовують об'єкти, повинна бути звільнена вручну, і, таким чином, першорядно ретельно розробити життєвий цикл складених об'єктів. Хоча різницю між агрегацією та складом все ще викладають у багатьох текстових підручниках, це істотно не має значення при програмуванні в середовищах з автоматичним управлінням пам'яттю. Якщо у вас є збір сміття, усі вони є лише складом, періодом.

З іншого боку, інкапсуляція є набагато більш загальним принципом, ніж те, що ви описуєте. Це перш за все ідея поєднання даних та функцій, які працюють над цими даними в одному модулі. Один із способів здійснити це - збереження приватного стану модуля та викриття змін у ньому через державні служби. Таким чином, клієнт не може отримати доступ до штату самостійно, але повинен повідомити модуль про їх намір, надсилаючи повідомлення. Таким чином, інкапсуляція не обмежується об'єктами, а стосується також послуг. Власне, один із способів дивитися на об’єкти - це дивитися на них як на послуги.

Ось приклад інкапсуляції

public class Counter {
    private int n = 0;
    public int inc() { return n++; }
}

або те саме за допомогою лямбда-функцій

var counter = (function() {
    var n = 0;
    var inc = function() { return n++; }
    return inc;
})();

В обох випадках дані, тобто змінна n, поєднуються разом із функцією, incяка працює на ній. І немає жодної можливості до будь-якої іншої функції n, тому ми маємо інкапсульований модуль, який забезпечує підрахунок як послугу.

Примітка: оголення всього внутрішнього стану об'єкта через приладдя насправді є порушенням інкапсуляції. На жаль, це таке поширене порушення, що багато хто буде плутати його з хорошим об’єктно-орієнтованим дизайном.

Інкапсуляція - це техніка зробити поля в класі приватними та забезпечити доступ до полів відкритими методами. Якщо поле оголошено приватним, до нього не може отримати доступ хтось поза класом, тим самим приховуючи поля всередині класу. З цієї причини інкапсуляцію також називають приховуванням даних.

    public class Test{

    private String name;

       private int age;

       public int getAge(){
          return age;
       }

       public String getName(){
          return name;
       }
    }

Див це питання також .

Асоціація вказує на зв’язок між об'єктами. наприклад: Комп'ютер використовує клавіатуру як пристрій введення.

Асоціація використовується тоді, коли один об’єкт хоче, щоб інший об’єкт виконував для нього послугу.

Агрегація - особливий випадок асоціації. Спрямована асоціація між об'єктами. Коли об'єкт має інший об'єкт, то ви отримаєте агрегацію між ними.

наприклад: У кімнаті є стіл, але стіл може існувати і без кімнати.

    class Room {

      private Table table;

      void setTable(Table table) {
        this.table = table;
      }

    }

Склад - особливий випадок агрегації. Склад більш обмежувальний. Коли є композиція між двома об'єктами, складений об'єкт не може існувати без іншого об'єкта. Це обмеження не існує в сукупності. наприклад: кімнати в будинку, які не можуть існувати протягом життя будинку.

    class House {

      private  Room room;

      House(Room roomSpecs) {
        room = new Room(roomSpecs);
      }

    }

Композиція - це технологія проектування, яка реалізує співвідношення "співвідношення" в класах або за спадщиною, або за об'єктом. Композиція для повторного використання коду.

Однією з найкращих практик в програмуванні Java є використання складу над успадкуванням

Використання цих прийомів зазвичай призводить до таких дизайнерських практик, як SOLID або різні шаблони дизайну .

Сенс використання шаблонів, практик та іншого полягає в описі вирішення конкретної проблеми, яка також є досяжною та розширюваною. Вам просто потрібно отримати достатній досвід, щоб сказати, де використовувати який візерунок чи техніку.

Я відверто відчуваю, що ці поняття, які викладаються в академічній формі, мають своє значення в контексті орієнтації на об'єкти та дизайну класів. Ці концепції нам дуже допомагають, коли мова йде про моделювання системи з нуля. Асоціація, агрегація та склад належать виключно до діаграми класів UML і абсолютно не залежать від технологічних обмежень, таких як проблеми з пам'яттю.

Крім того, ви також повинні враховувати вищі рівні або бізнес-цілі системи, яку ви моделюєте. У нашій системі, що розглядається, у нас є такі об'єкти, як «Будинок та Кімната», але вони не можуть бути сильно пов’язані (за допомогою композиції). Наприклад, якщо я моделю систему нерухомості, то, можливо, я повинен знати, яка кімната належить до якого будинку. Але давайте, я буду моделювати систему опитування чи перепису, де я хочу знати, скільки людей живе в кожній кімнаті будинку в певній місцевості, тоді мені просто не потрібно співвідносити кімнату з будинком за складом.

Іншим прикладом може бути фруктовий сад та певний вид фруктів. Скажімо, я розглядаю фруктовий сад лише тоді, коли в ньому посаджені яблуні. Суть полягає в тому, що вимоги загальної системи мають велике значення.

Інкапсуляція - один із стовпів об'єктно-орієнтованого дизайну. Вам потрібно поєднати свої дані та операції, які ви будете виконувати над своїми даними. також ви повинні приховати певні атрибути вашого об'єкта від зовнішнього світу, щоб дозволити йому вижити у дійсному стані. Коли 2 об’єкти взаємодіють, вони повинні взаємодіяти один з одним через інтерфейс. І саме це забезпечує інкапсуляція, коли ми розробляємо нашу систему OO.

Ось як ці поняття застосовуються до коду:

АСОЦІАЦІЯ: Асоціація вказує на зв’язок між об'єктами. Це дозволяє програмісту знати, які методи писати на своїх класах, щоб змусити їх взаємодіяти один з одним. Ви можете знайти кілька прикладів діаграм коду та класу, щоб зрозуміти асоціацію. У вашому прикладі викладача та учня є взаємозв'язок викладання та викладання . Тож ви просто напишете набір методів (технічно названий інтерфейс), за допомогою яких ви зможете дізнатись, який учень має, які викладачі та який викладач, які учні. Асоціація також дозволяє системному модельєру допомогти дизайнеру бази даних про атрибути та поля, які потрібно зберігати в базі даних.

СКЛАД: Якщо один об’єкт є невід'ємною частиною іншого об'єкта, тоді мені, можливо, доведеться вказати цю залежність у конструкторі іншого об'єкта. Наприклад, у вашому сценарії "Будинки та кімнати" ми можемо написати наступний код на випадок, якщо хочемо знати, яка кімната належить до якого типу будинку.

class House{
          string _HouseType;   
     public:    
    void setHouseType(string house_type)
     {
        this. _HouseType = house_type;
     } 

     string getHouseType()
    {
       return _HouseType;
    }
};



 House HouseObject = new House();


class Room{

 public: 
 Room(string HouseType) {
       this._HouseType = HouseObject.getHouseType();  //as in my system a room cannot exist without a house

 } 

};

Програміст також гарантуватиме , що викликає деструктори об'єкта, що також буде викликано деструктор іншого об'єкта. Це є вирішальним.

АГРЕГАЦІЯ: Скажімо, якщо зв’язок між об'єктами слабкий, то ми для програміста, це означатиме використання змінної екземпляра замість цього для позначення зв'язку. А потім напишіть мутаторний функтон (сеттер), щоб надати цьому об'єкту значення з іншого.

class Department{

 string dept_name;

public:
   void setDeptName(string name)
   {
        this.dept_name=name;
   }

   string getDeptName()
   {
        return dept_name; 
   }

};



 Department DepartmentObject = new Department();

class Teacher{

 string dept_name;

public:

  setDeptName(string name)
  {
     this.dept_name = DepartmentObject.getDeptName();  //You only need to invoje this method when needed (aggregation)
  }
}

};

Гаразд, давайте відобразимо це на деякі основні властивості, а не на абстрактні поняття, які мають сенс лише після того, як ви зрозумієте, що вони означають. Як і деякі коментатори, я не згоден з прийнятою відповіддю, я кажу, що це поняття, незалежні від управління пам’яттю.

Інкапсуляція

Ви хочете приховати складність від клієнта, лише публікуючи речі, які мають значення з точки зору клієнта, полегшуючи роботу для клієнта. Як бонус ви отримуєте впевненість, що з інкапсульованим кодом нічого не можна зіпсувати. Поки ви поважаєте інтерфейс та функціональність, ви можете переробляти матеріали та бути впевненими, що нічого не зламаєте. Залежність є лише від опублікованого інтерфейсу.

Інкапсуляція - один з основних стовпів орієнтації об'єкта. Це не шаблон, це принцип, і він може застосовуватися як до логіки, так і для даних. Це лише основна перевага використання класів в першу чергу, а не те, що ви бачите прямо в діаграмі чи проектному документі.

Асоціація

Це дуже вільне поняття, яке в основному описує лише залежність між об'єктами. Один об’єкт знає про існування іншого об’єкта і може використовувати його функціонал в якийсь момент. На діаграмі асоціація попередить вас, що існує залежність і що зміна одного об'єкта може вплинути на інший. Це не техніка, яка застосовується, коли у вас є якась проблема, яку потрібно вирішити, це більше схожий на факт життя, про який слід знати, коли він є. Це стосунки. Як і рахунок-фактура, що має властивість Замовлення. І Порядок, і Рахунок мають свій життєвий цикл. Один стосується товарів, а другий - про оплату, що по суті робить їх незалежними, але важливо знати, за які товари платять.

Утримання

Я додаю це, тому що воно належить до серії та зробить агрегацію більш значущою. Я більше не чую термін, який використовується в контексті SE, але я думаю, що він все ще корисний. Зміщення передбачає інкапсуляцію, але суворо стосується примірників об'єктів, приватних для класу, що містить. Функціональність об'єктів, що містяться, вибірково піддається публічним інтерфейсам. Клас, що містить, керує життєвим циклом керованих об'єктів. Ви використовуєте це, коли вам потрібні деякі функції існуючого класу, щоб зробити клас, що містить функціонал. Це може бути аналізатор XML, і клієнт класу, що містить, ніколи не може бачити і не знати нічого, що стосується XML. Як метафору, подумайте про об'єкт, що міститься, як працівник бек-офісу. Клієнти ніколи не зустрічаються з цими людьми, але вони потрібні для надання послуги.

Агрегація

Це дуже схоже на стримування, за винятком контролю життєвого циклу та видимості об'єднаних об'єктів. Сукупні об'єкти вже доступні в іншому контексті та ними керує інша сутність. Агрегатор просто пропонує фасад, портал для об'єднаних об'єктів. Коли клієнт звертається до агрегату, він отримує інтерфейс самого об'єкта сукупності, а не обгортку навколо нього. Суть сукупності пропонує логічне групування речей. Подумайте про точку доступу до служб або якогось іншого об’єкта обгортки.

Склад

Мені здається, це більш сучасний термін для стримування, можливо, тому, що він був введений у популярну книгу порівняно недавнього походження. Якщо стримування фокусується на технічних аспектах об'єктних відносин, композиція зазвичай використовується в контексті проектних рішень, точніше як більш гнучка альтернатива успадкування.

Це не багато говорить про природу об'єктних відносин чи власності, це лише вказує на те, що функціональність реалізується за допомогою поєднання функціональності існуючих класів. Тому я заперечую, що вона не належить до цієї серії, оскільки вона нічого не говорить про технічні аспекти впровадження, де це роблять інші.