Please enable JavaScript.
Coggle requires JavaScript to display documents.
Наследование и композиция - Coggle Diagram
Наследование и композиция
Это механизмы повторного использования
Наследование
Отношение
родительский класс/дочерний
Каждое новое наследование создаёт контекст для использования уже унаследованных методов, поэтому всё равно тщательно тестиоруем
Концпепция "обобщение-конкретизация"(тоже стоит уделить внимание)
Композиция
Создание объектов с помощью других объектов
Тип объекта, который состоит из других объектов
Составной
Агрегированный и ассоциированный
Агрегация
UML: Линия с ромбом
Ромб обозначает, какому классу принадлежит этот класс(содержит как часть)
Однако объект не всегда может включать определённое кол-во объектов или некоторых из них вообще
Нужно решать, каким будет качество и сложность, ибо детализация композиции не ограничена
Ассоциация
UML: Просто линия
Обобщённый
Наследования лучше избегать и предпочитать композицию
Нельзя быть уверенным в том, что все подклассы будут вести себя как задумано (пример с птицами, их методом fly() и пингвинами с страусами(для них нету смысла иметь этот метод))
(больше примера. А что было бы, если бы пингвин решил опробывать метод fly и удивился бы, если бы вместо полёта он ходил, а тем временем он уже спрыгнул с обрыва для полёта)
Наследование ослабляет инкапсуляцию в иерархии классов(ибо изменение суперкласса вызовет волновой эффект во всех подклассах)
Это усложняет тестирование
Для снижения таких рисков нужно придерживаться строго условия "является экземпляром"
Т.е. конкретизация. От класса с интерфейсом до класса с реализацией,
Чем б
о
льшую общность выделяю, тем сложнее становится программа
Головоломка: точная модель или менее сложная система?
В крупных системах сохранение простоты
В менее крупных - точность
Решения о простоте и функциональности должно быть сбалансированным
С учётом будущего
Абстрактные классы, методы и протоколы
Подклассы не могут наследовать какой-либо код от протокола, вследствии его нельзя использовать также, как и абстрактный класс