Какая польза от объединения, агрегации и состава?

Я прошел через множество теорий о том, что такое инкапсуляция и три метода ее реализации, а именно: ассоциация, агрегация и композиция.

То, что я нашел, это :

Инкапсуляция

Инкапсуляция - это техника, делающая поля в классе приватными и обеспечивающая доступ к полям с помощью открытых методов. Если поле объявлено как личное, оно не может быть доступно никому за пределами класса, тем самым скрывая поля внутри класса. По этой причине инкапсуляция также называется скрытием данных.

Инкапсуляция может быть описана как защитный барьер, который предотвращает случайный доступ кода и данных к другому коду, определенному вне класса. Доступ к данным и коду строго контролируется интерфейсом.

Основным преимуществом инкапсуляции является возможность изменять наш реализованный код, не нарушая код тех, кто использует наш код. С помощью этой функции Encapsulation обеспечивает удобство, гибкость и расширяемость нашего кода.

ассоциация

Ассоциация - это отношения, в которых все объекты имеют свой жизненный цикл, и у них нет владельца. Давайте возьмем пример Учителя и Студента. Несколько учеников могут связываться с одним учителем, а один ученик может связываться с несколькими учителями, но между объектами нет права собственности, и оба имеют свой жизненный цикл. Оба могут создавать и удалять независимо.

агрегирование

Агрегация - это специализированная форма объединения, где все объекты имеют свой жизненный цикл, но есть право собственности, и дочерний объект не может принадлежать другому родительскому объекту. Давайте возьмем пример кафедры и преподавателя. Один учитель не может принадлежать нескольким отделам, но если мы удалим отдел, объект учителя не будет уничтожен. Мы можем думать об этом как об отношениях «есть».

Сочинение

Композиция снова является специализированной формой агрегации, и мы можем назвать это «смертью» отношений. Это сильный тип агрегации. Дочерний объект не имеет своего жизненного цикла, и если родительский объект удаляет все дочерние объекты, они также будут удалены. Давайте снова возьмем пример отношений между Домом и комнатами. Дом может содержать несколько комнат, но в нем нет самостоятельной жизни, и любая комната не может принадлежать двум разным домам. Если мы удалим дом, комната будет автоматически удалена.

Вопрос в том:

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

Различие между ассоциацией, агрегацией и композицией, как вы ее описываете, является наследием, восходящим к старым временам ручного управления памятью. Например, в 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);
      }

    }

Композиция - это метод проектирования для реализации отношения has-a в классах, либо по наследованию, либо по составлению объекта для повторного использования кода.

Одна из лучших практик в Java-программировании - использовать композицию вместо наследования.

Использование этих методов обычно приводит к таким методам проектирования, как SOLID или различные шаблоны проектирования .

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

Я откровенно чувствую, что эти понятия, преподаваемые в академических кругах, имеют свое значение в контексте объектной ориентации и дизайна класса. Эти концепции очень помогают нам, когда дело доходит до моделирования системы с нуля. Ассоциация, агрегация и композиция принадлежат исключительно диаграмме классов UML и полностью независимы от технологических ограничений, таких как проблемы с памятью.

Кроме того, вы также должны учитывать более высокий уровень или бизнес-цели системы, которую вы моделируете. В нашей системе есть такие объекты, как Дом и Комната, но они не могут быть тесно связаны (посредством композиции). Например, если я моделирую систему недвижимости, то, возможно, мне придется знать, какая комната принадлежит какому дому. Но позвольте мне смоделировать систему опроса или переписи, где я хочу знать, сколько людей живет в каждой комнате дома в определенной области, тогда мне просто не нужно связывать комнату с домом через композицию.

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

Инкапсуляция является одним из столпов объектно-ориентированного дизайна. Вам необходимо связать свои данные и операции, которые вы будете выполнять над своими данными. также вы должны скрыть определенные атрибуты вашего объекта от внешнего мира, чтобы позволить этому объекту выжить в допустимом состоянии. Когда 2 объекта взаимодействуют, они должны взаимодействовать друг с другом через интерфейс. И это то, что обеспечивает инкапсуляция при разработке нашей ОО-системы.

Вот как эти понятия применяются к коду:

АССОЦИАЦИЯ: Ассоциация указывает на связь между объектами. Это позволяет программисту знать, какие методы писать в своих классах, чтобы они взаимодействовали друг с другом. Вы можете найти несколько примеров кода и диаграмм классов, чтобы понять связь. В вашем примере «Обучай и ученик» существует взаимосвязь между преподаванием и обучением . Таким образом, вы просто напишите набор методов (технически называемый интерфейс), с помощью которых вы сможете узнать, у какого учащегося есть какие учителя, а у какого учителя какие ученики. Ассоциация также позволяет разработчику модели системы помочь разработчику базы данных об атрибутах и ​​полях, которые необходимо сохранить в базе данных.

СОСТАВ: Если один объект является неотъемлемой частью другого объекта, то мне, возможно, придется указать это отношение в конструкторе другого объекта. Например, в вашем сценарии «Дома и комнаты» мы можем написать следующий код на тот случай, если мы хотим узнать, какая комната принадлежит какому типу дома.

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

 } 

};

Программист также будет гарантировать, что при вызове деструкторов объекта также будет вызван деструктор другого объекта. Это очень важно.

AGGREGATION: допустим, если связь между объектами слабая, то для программиста мы будем использовать вместо нее переменную экземпляра для обозначения этой связи. А затем напишите функцию-мутатор (setter), чтобы предоставить значение этому объекту из другого объекта.

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)
  }
}

};

Хорошо, давайте сопоставим это с некоторыми основными свойствами, а не с абстрактными понятиями, которые имеют смысл только после того, как вы поймете, что они означают. Как некоторые комментаторы, я не согласен с принятым ответом, я говорю, что это концепции, независимые от управления памятью.

Инкапсуляция

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

Инкапсуляция является одним из основных столпов ориентации объекта. Если это не шаблон, это принцип, и он может применяться как к логике, так и к данным. Во-первых, это просто основное преимущество использования классов, а не то, что вы явно указали бы в диаграмме или проектном документе.

ассоциация

Это очень свободная концепция, которая в основном описывает просто зависимость между объектами. Один объект знает о существовании другого объекта и может использовать его функциональность в какой-то момент. На диаграмме ассоциация предупреждает вас о наличии зависимости и о том, что изменение одного объекта может повлиять на другой. Это не техника, которую нужно применять, когда вам нужно решить какую-то проблему, это больше похоже на факт жизни, о котором вы должны знать, когда он там есть. Это отношения. Как счет, имеющий свойство Orders. И Заказ, и Счет имеют свой жизненный цикл. Один касается товаров, а другой - об оплате, что по сути делает их независимыми, но важно знать, за какие товары они оплачиваются.

политика сдерживания

Я добавляю это, потому что это относится к серии и сделает агрегирование более значимым. Я больше не слышал, чтобы этот термин использовался в контексте SE, но я думаю, что он все еще полезен. Сдерживание подразумевает инкапсуляцию, но строго относится к экземплярам объекта, частным для содержащего класса. Функциональность содержащихся объектов выборочно предоставляется через общедоступные интерфейсы. Содержащий класс управляет жизненным циклом контролируемых объектов. Вы используете это, когда вам нужны некоторые функции существующего класса, чтобы сделать содержащийся класс функциональным. Это может быть синтаксический анализатор XML, и клиент содержащего класса может никогда не увидеть или не знать ничего, связанного с XML. В качестве метафоры воспринимайте содержащийся объект как работника бэк-офиса. Клиенты никогда не встречают этих людей, но они необходимы для предоставления услуг.

агрегирование

Это очень похоже на сдерживание, за исключением контроля жизненного цикла и видимости агрегированных объектов. Агрегированные объекты уже доступны в другом контексте и управляются другим объектом. Агрегатор просто предлагает фасад, портал для агрегированных объектов. Когда клиент обращается к агрегату, он получает интерфейс самого объекта агрегата, а не оболочку вокруг него. Точка совокупности предлагает логическую группировку вещей. Подумайте о точке доступа к сервисам или какому-либо другому объекту-оболочке.

Сочинение

Мне кажется, что это более современный термин для сдерживания, возможно, потому что он был введен в популярную книгу относительно недавнего происхождения. В тех случаях, когда локализация фокусируется на технических аспектах объектных отношений, композиция обычно используется в контексте проектных решений, более конкретно, в качестве более гибкой альтернативы наследования.

Это не говорит много о природе объектных отношений или собственности, это просто указывает на то, что функциональность реализуется путем объединения функциональности существующих классов. Поэтому я бы сказал, что он не относится к этой серии, потому что он ничего не говорит о технических аспектах реализации, которой занимаются другие.