Характеристики плохого объектно-ориентированного дизайна

Question

Я читаю об объектно-ориентированных принципах дизайна. Я столкнулся с особенностями плохого дизайна.

1. Это трудно изменить, потому что каждое изменение влияет слишком много других частей системы. (Жесткость)
2. Когда вы совершаете изменения, неожиданные части системы ломаются. (Fragility)
3. Трудно повторное использование в другом приложении, потому что оно не может быть , выведенное из текущего приложения. (Неподвижность)

Я могу понять первые два, но третий один мало для меня трудно понять. Речь идет об извлечении общих функций связанных классов в базовом классе, что делает методы из повторяющегося кода? Но он говорит hard to reuse in another Application. Обычно мы пишем контекстный код и Over-engineering - это не очень хорошая идея, у нас есть хорошие принципы, такие как YAGNI. Я нахожу эти идеи немного противоречивыми.

Просьба представить ваши ценные мысли для этого.

Answer 1

мобильность Пример:

Примем следующие классы:

1. животных
2. Canine
3. Собака

Как и следовало ожидать, Canine расширяет Animal и Dog расширяет Canine.

Один из способов плохо спроектировать Animal - это метод talk(), который печатает bark. Возможно, первоначальное намерение этой заявки было только для собак, и поэтому метод лая talk был прекрасен. Но повторное использование этого в другой кодовой базе приведет к проблемам.

Скажите, мы хотим увеличить Animal и создать Bird. Птицы не лают :)

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

Можно утверждать, что класс Bird может переопределить метод talk. Это будет работать, однако, другой разработчик, расширяющий Animal, по другой причине может забыть переопределить этот метод ... и т. Д.

Я знаю, что это не лучший пример, но он демонстрирует проблему.