Разумные причины создания классов

Моделирование объектов реального мира Создайте класс для каждого объекта реального мира, моделируемого вашей программой.

Моделирование абстрактных объектов Прекрасный пример - классический обьект Shape (фигура). Нахождение адекватных абстрактных объектов – одна из главных проблем ООП.


Снижение сложности – самая важная причина создания класса (сокрытие деталей, минимизация объема кода, облегчение сопровождения программы). 

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


Облегчение повторного использования кода


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

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

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

Принцип достановки Лисков (LSP)

«Клиенты должны иметь возможность использования подклассов через интерфейс базового класса, не замечая никаких раздичий» (Hunt and Thomas, 2000)

Вроде очевидные вещи, но, думаю, многих людей название смутило бы...

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

Сокрытие информации

Размышление о том, что скрыть, способствует принятию удачных решений на всех уровнях проектирования. Оно подталкивает к применению именованных констант вместо чисел на уровне конструирования, помогает выбирать удачные имена методов классов и их параметров и указывает на грамотные варианты декомпозиции и реализации взаимодействия классов и подсистем на уровне системы.
Почаще задавайте себе вопрос “Что мне скрыть?”, и вы удивитсь, сколько проблем проектирования расстает на ваших глазах.
...

В юбилейном 20-летнем издании книги «Мифически человеко-месяц» Фред Брукс пришел к выводу, что критика сокрытия информации была одной из ошибок, допущенных им в первом издании книги. «Парнас был прав в отношении сокрытия информации, а я ошибался», - признался он (Brooks, 1995).

Программа не должна содержать циклических отношений, при которых класс А использует класс В, класс В использует класс С, а класс С - класс А.

Желательные характеристики проекта

• Минимальная сложность
• Простота сопровождения
• Слабое сопряжение
• Расширяемость
• Возможность повторного использования
• Высокий коэффициент объединения по входу (к конкретному классу обращается большое число других классов)
• Низкий или средний коэффициент  разветвления по выходу (конкретный класс обращается к малому или среднему числу других классов)
• Портируемость
• Минимальная, но полная функциональность
• Стратификация (отсутствие в системе лишних частей)
• Соответствие стандартным методикам