Избегайте наследования при разработке ООП-программного обеспечения? скачать в хорошем качестве

Избегайте наследования при разработке ООП-программного обеспечения?

Наследование — ключевая особенность ООП. Очень важно точно знать, как оно работает и что с ним можно делать. Уверен, вы уже довольно хорошо знакомы с этой темой. Поэтому, уверен, вы знаете все случаи, когда оно полезно, но как насчёт обратного? Когда следует избегать наследования в разработке ПО? #программирование #технологии #разработка ПО #быстрый ответ Очевидно, что вы захотите использовать наследование во всех объектно-ориентированных языках: C++, C#, Java, Go... Постойте. Нет, Go — это не вариант, в нём нет наследования. В любом случае, некоторые языки поддерживают объектно-ориентированную парадигму полнее других. Например, C++ предлагает множественное наследование. Всё верно — у каждого класса может быть несколько родительских классов. Стандарт даже гласит, что каждый компилятор должен поддерживать не менее 1024 родительских классов. Краткое напоминание: наследование расширяет класс новыми полями и методами, создавая дочерний класс из выбранного класса. Этот дочерний класс получил новое имя и «наследует» все свойства своего родителя. Представьте себе, что родительский класс встраивается в свой дочерний. Мы, программисты, часто пишем новые классы, и иногда возникает необходимость сделать выбор: должны ли эти два класса быть связаны и как? Есть несколько общеизвестных правил, которые помогут вам определиться, а также несколько менее известных. Я расскажу об обоих, так что оставайтесь со мной. Итак, два класса определённо связаны, но связаны ли они наследованием или композицией? (Композиция — это когда один класс имеет поле со ссылкой на объект другого класса). В данном случае мы будем следовать принципу отношения «является-есть-имеет-а». Допустим, у нас есть несколько классов: «Звезда», «Цвет» и «Форма». «Звезда является-формой», поэтому это может быть отношение наследования, но «Звезда имеет-цвет», поэтому это композиция. «Форма» не является цветом, но, возможно, могла бы иметь цвет, если бы нам хотелось. Другой очень распространённый пример — классы «Автомобиль», «Грузовик» и «Двигатель». Можете ли вы организовать их в возможные иерархии? Итак, я упомянул основные общие правила. Какова менее известная, но более веская причина избегать наследования? «Банда четырёх», или отцы парадигм проектирования, называют наследование повторным использованием по принципу «белого ящика», когда все детали реализации родительского класса видны дочернему. Композиция же называется повторным использованием по принципу «чёрного ящика» — реализация каждого класса закрыта, инкапсулирована от другого. Инкапсуляция, как мы знаем, — ещё одна ключевая особенность ООП: когда один класс наследует от другого, родительский класс отдаёт часть своей инкапсуляции, чтобы создать дочерний класс. У этого есть и плюсы, и минусы: такой дочерний класс проще написать. Однако (и это важно) могут возникнуть сложности, когда вы попытаетесь изменить представление или реализацию родительского класса. Потому что очень легко зависеть от родительского класса — а большинство дочерних классов так и поступают. Другая проблема — перманентность такой связи: наследование существует вечно: когда вы выбираете дочерний класс во время компиляции, вы не сможете изменить его во время выполнения, вам придётся уничтожить объект и создать новый, в отличие от композиции, где вы можете менять и переключаться между ними как угодно. Используя композицию, мы также достигаем двух других целей. Во-первых: мы следуем ещё одному важному правилу чистого кода: единственной ответственности. Если класс наследуется от слишком большого количества родительских классов, скорее всего, он больше не служит одной цели. Во-вторых: наша метрика сложности кода, называемая глубиной дерева наследования (DIT), останется низкой. Слишком сложный код — проклятие каждого программиста. Бдительность поможет вам и вашим коллегам лучше спать по ночам. Подписывайтесь, и увидимся в следующем выпуске, ура!