Предпочитаете композицию наследству?

While in short words I would agree with "Prefer composition over inheritance", very often for me it sounds like "prefer potatoes over coca-cola". There are places for inheritance and places for composition. You need to understand difference, then this question will disappear. What it really means for me is "if you are going to use inheritance - think again, chances are you need composition".

You should prefer potatoes over coca cola when you want to eat, and coca cola over potatoes when you want to drink.

Creating a subclass should mean more than just a convenient way to call superclass methods. You should use inheritance when subclass "is-a" super class both structurally and functionally, when it can be used as superclass and you are going to use that. If it is not the case - it is not inheritance, but something else. Composition is when your objects consists of another, or has some relationship to them.

So for me it looks like if someone does not know if he needs inheritance or composition, the real problem is that he does not know if he want to drink or to eat. Think about your problem domain more, understand it better.

Когда вы хотите «скопировать» / раскрыть API базового класса, вы используете наследование. Если вы хотите только «скопировать» функциональность, используйте делегирование.

Один из примеров: вы хотите создать стек из списка. В стеке есть только щелчки, толчки и взгляды. Вы не должны использовать наследование, поскольку вам не нужны функции push_back, push_front, removeAt и т. Д. В стеке.

Если вы понимаете разницу, это проще объяснить.

Процедурный код

Примером этого является PHP без использования классов (особенно до PHP5). Вся логика закодирована в наборе функций. Вы можете включать другие файлы, содержащие вспомогательные функции и т. Д., И вести бизнес-логику, передавая данные в функциях. По мере роста приложения это может быть очень сложно. PHP5 пытается исправить это, предлагая более объектно-ориентированный дизайн.

Наследование

Это поощряет использование классов. Наследование - это один из трех принципов объектно-ориентированного проектирования (наследование, полиморфизм, инкапсуляция).

class Person {
   String Title;
   String Name;
   Int Age
}

class Employee : Person {
   Int Salary;
   String Title;
}

Это наследование в действии. Сотрудник "является" Человеком или наследуется от Человека. Все отношения наследования являются отношениями «как». Employee также затеняет свойство Title от Person, то есть Employee.Title будет возвращать Title для Employee, а не Person.

Состав

Состав предпочтительнее наследования. Проще говоря, у вас будет:

class Person {
   String Title;
   String Name;
   Int Age;

   public Person(String title, String name, String age) {
      this.Title = title;
      this.Name = name;
      this.Age = age;
   }

}

class Employee {
   Int Salary;
   private Person person;

   public Employee(Person p, Int salary) {
       this.person = p;
       this.Salary = salary;
   }
}

Person johnny = new Person ("Mr.", "John", 25);
Employee john = new Employee (johnny, 50000);

Композиция обычно «имеет» или «использует» отношения. Здесь у класса Employee есть Person. Он не наследуется от Person, а вместо этого получает объект Person, переданный ему, поэтому он «имеет» Person.

Композиция вместо наследования

Теперь предположим, что вы хотите создать тип Manager, чтобы в итоге вы получили:

class Manager : Person, Employee {
   ...
}

Этот пример будет работать нормально, однако что, если и Person, и Employee объявят Title ? Должен ли Manager.Title возвращать «Операционный менеджер» или «Мистер»? При компоновке эта неоднозначность лучше обрабатывается:

Class Manager {
   public string Title;
   public Manager(Person p, Employee e)
   {
      this.Title = e.Title;
   }
}

Объект Manager состоит из Employee и Person. Поведение Title взято от сотрудника.

With all the undeniable benefits provided by inheritance, here's some of its disadvantages.

Disadvantages of Inheritance:

1. You can't change the implementation inherited from super classes at runtime (obviously because inheritance is defined at compile time).
2. Inheritance exposes a subclass to details of its parent class implementation, that's why it's often said that inheritance breaks encapsulation (in a sense that you really need to focus on interfaces only not implementation, so reusing by sub classing is not always preferred).
3. The tight coupling provided by inheritance makes the implementation of a subclass very bound up with the implementation of a super class that any change in the parent implementation will force the sub class to change.
4. Excessive reusing by sub-classing can make the inheritance stack very deep and very confusing too.

On the other hand Object composition is defined at runtime through objects acquiring references to other objects. In such a case these objects will never be able to reach each-other's protected data (no encapsulation break) and will be forced to respect each other's interface. And in this case also, implementation dependencies will be a lot less than in case of inheritance.

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

Наследование иногда полезно, если иерархия действительно представляет собой связь. Это относится к принципу открытости-закрытости, который гласит, что классы должны быть закрыты для модификации, но открыты для расширения. Таким образом, у вас может быть полиморфизм; иметь общий метод, который имеет дело с супертипом и его методами, но через динамическую отправку вызывается метод подкласса. Это гибко и помогает создать косвенное обращение, что очень важно в программном обеспечении (чтобы меньше знать о деталях реализации).

Наследование, тем не менее, легко злоупотребляет и создает дополнительную сложность с жесткими зависимостями между классами. Кроме того, понимание того, что происходит во время выполнения программы, довольно сложно из-за слоев и динамического выбора вызовов методов.

Я бы предложил использовать компоновку по умолчанию. Он более модульный и дает преимущество позднего связывания (вы можете изменять компонент динамически). Также проще тестировать вещи по отдельности. И если вам нужно использовать метод из класса, вы не обязаны иметь определенную форму (принцип подстановки Лискова).

Кроме того, понимание того, что происходит во время выполнения программы, довольно сложно из-за слоев и динамического выбора вызовов методов.

Я бы предложил использовать компоновку по умолчанию. Он более модульный и дает преимущество позднего связывания (вы можете изменять компонент динамически). Также проще тестировать вещи по отдельности. И если вам нужно использовать метод из класса, вы не обязаны иметь определенную форму (принцип подстановки Лискова).

Кроме того, понимание того, что происходит во время выполнения программы, довольно сложно из-за слоев и динамического выбора вызовов методов.

Я бы предложил использовать компоновку по умолчанию. Он более модульный и дает преимущество позднего связывания (вы можете изменять компонент динамически). Также проще тестировать вещи по отдельности. И если вам нужно использовать метод из класса, вы не обязаны иметь определенную форму (принцип подстановки Лискова).

Чего вы хотите заставить себя (или другого программиста) придерживаться и когда вы хотите предоставить себе (или другому программисту) больше свободы. Утверждалось, что наследование полезно, когда вы хотите заставить кого-то использовать способ решения / решения конкретной проблемы, чтобы они не могли свернуть в неверном направлении.

Is-a и Has-a - полезное практическое правило.

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

Наследование, вероятно, является худшей формой муфты, которую вы можете иметь

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

Статья, Наследование - это зло: Epic Fail из даматичныхannotationsModelBinder , проходит через пример этого в C #. Это показывает использование наследства, когда должна была быть использована композиция, и как оно может быть восстановлено.