Принципов объектно-ориентированного дизайна

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

2. Сначала заставь работать, потом ускоряй. Это верно, даже если вы уверены, что фрагмент кода действительно важен и будет основным узким местом в вашей системе. Не торопитесь. Сперва заставьте систему работать с настолько простым решением задачи, насколько это возможно. Уже потом, если решение оказалось не достаточно быстрым, профилируйте его. Почти всегда вы обнаружите, что ваше мнимое узкое место не проблема. Потратьте время на более важные вещи.

3. Помните принцип «Разделяй и властвуй». Если проблема, которой вы занимаетесь, слишком сложна, попробуйте вообразить, как должна работать программа, если некий черный ящик скроет все сложности. Этот черный ящик — объект. Напишите сначала код, который использует объект, а потом рассмотрите проблемный объект еще раз и инкапсулируйте его сложности в другие объекты.

4. Отделите создателя класса, от его пользователя (программиста-клиента). Пользователь класса — это своего рода «покупатель», и ему не интересно, что происходит внутри класса. Создатель класса должен быть экспертом в своем деле и создавать код так, чтобы даже использование его начинающим программистом, было работоспособным и эффективным. Библиотеку использовать легко, только если способ ее использования прозрачен.

5. Когда создаете класс, постарайтесь использовать такие имена, чтобы комментарии не понадобились. Ваша цель сделать программный интерфейс модуля концептуально простым. Для этого используйте, по возможности, перегрузку методов.

6. Анализ и дизайн должны определить, как минимум, классы вашей системы, их открытые интерфейсы и их отношения с другими классами, в особенности — базовыми. Если ваш способ разработки производит более того, спросите себя, все ли произведенное имеет значение на протяжении жизненного цикла программы. Если нет, поддержка лишнего влетит вам в копеечку. Участники групп разработки стараются не поддерживать ничего, что не способствует их продуктивности. Фактически, многие методологии разработки этого не учитывают.

7. Все проблемы разработки ПО могут быть упрощены добавлением дополнительного уровня концептуального обобщения. Это фундаментальное правило разработки ПО является основой абстракции, наиважнейшей особенности объектно-ориентированного программирования.

8. Обобщение должно иметь значение. Это значение может быть столь простым как «совмещение часто используемого кода в одном методе». Если вы добавляете уровни обобщения (абстракции, инкапсуляции и пр.), которые не имеют значения, это столь же плохо, как не иметь их вообще.

9. Делайте классы настолько атомарными, насколько это возможно. Давайте каждому классу единственное, четкое предназначение. Если ваши классы или вся система становятся слишком сложными, разбейте сложные классы на более простые. Самый простой индикатор — размер, если класс слишком большой, есть вероятность, что он делает слишком много и должен быть декомпозирован. Ключом к переработке класса может быть:

o Сложный switch(оператор выбора): попробуйте использовать полиморфизм.

o Большое количество методов, охватывающих очень разные типы операций: следует использовать несколько классов.

o Большое количество переменных-членов класса, которые определяют очень разные параметры: следует использовать несколько классов.

10. Следите за длинными списками параметров. Вызов метода становится труднее читать, записывать и поддерживать при росте списка параметров. Вместо этого, попробуйте разместить метод в соответствующем классе и/или передавать параметры в виде объектов.

11. Не повторяйтесь. Если фрагмент кода повторяется во многих методах производных классов, поместите этот код в один метод базового класса и вызывайте этот метод из методов производных классов.

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

13. Не расширяйте базовую функциональность с помощью подклассов. Если элемент интерфейса важен для класса, он должен находиться в базовом классе, а не добавляться при наследовании. Если вы добавляете методы в производных классах, возможно, стоит переосмыслить весь дизайн.

14. Меньшее — это большее.Начните с минимального интерфейса класса, настолько маленького и простого, насколько вообще позволяет решение текущей задачи. Не пытайтесь предвидеть все способы, которыми ваш класс может быть использован. Напротив, используя класс, вы обнаружите, как еще стоит расширить интерфейс. Однако, если класс уже используется, невозможно расширить интерфейс без изменения клиентского кода. Если нужно добавить новые методы — клиентский код не изменится. Но если новые методы заменят функциональность старых, лучше оставить старый интерфейс (вы можете объединить функциональность в последующей реализации, если захотите). Если нужно расширить интерфейс существующего метода добавлением новых аргументов, создайте перегруженный метод с новыми аргументами. Такой способ никак не помешает существующим вызовам того метода.

15. Прочтите ваши классы вслух, чтобы убедиться, что они логичны. Отношение между производным и базовым классом произносите как «есть», а между классом и объектами-членами как «имеет, содержит».

16. Когда выбираете между наследованием и композицией, спросите себя требуется ли приведение к базовому типу. Если нет, выбирайте композицию(объекты-члены). Это устранит необходимость в существовании множества базовых типов. Если выберете наследование, пользователи будут думать, что предполагается приведение к базовому типу.

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

18. Следите за перегрузкой. Метод не должен исполнять код условно в зависимости от типа значения аргумента. В этом случае следует создать два или более перегруженных метода взамен.

19. Иногда помогает простая агрегация. Система комфорта пассажиров на авиалиниях состоит из разрозненных элементов: сидения, кондиционера, видео и т.п., и таких комплектов в самолете много. Вы создали частные (private) члены класса и построили полностью новый интерфейс? Не в этом случае. Компоненты так же являются частью открытого интерфейса, так что необходимо создавать открытые (public) члены класса. Такие объекты имеют собственные частные реализации, которые по прежнему безопасны. Простую агрегацию не следует применять часто, но иногда без нее не обойтись.

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

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

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

23. Объекты не должны просто хранить данные. Они должны иметь также четко определенное поведение. Кстати, «объекты данных» — это правильное решение, но только когда используется для упаковки и транспортировки группы элементов в случае, если их обобщенный контейнер неадекватен задаче.

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

25. Используйте наследование и перекрытие методов для выражения разницы в поведении и поля для выражения различий состояний.Предельный пример того, чего не следует делать — это наследование различных классов для определения цветов вместо использования поля «цвет».

26. Избегайте несогласованности. Два семантически разных объекта могут иметь идентичные действия, или задачи и естественно будет искушение попытаться сделать одно подклассом другого, просто чтобы воспользоваться наследованием. Это называется несогласованностью, но нет никакого оправдания созданию связки суперкласс-подкласс там, где она не существует. Лучшим решением будет создать общий базовый класс, который предоставит интерфейс для обоих производных классов. Это займет чуть больше места, но наследование будет полезным и возможно позволит обнаружить нечто важное в дизайне.

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

28. Используйте шаблоны проектирования для уничтожения «голой функциональности». То есть, если только один объект вашего класса должен быть создан, вставляйте код в приложение с комментарием «сделать только раз». Оберните его в шаблон «Одиночку». Если у вас много беспорядочного кода, который создает ваши объекты, в главной программе, поищите созидательный шаблон, вроде «фабричного метода», в который вы сможете инкапсулировать создание объектов. Устранение «голой функциональности» не только сделает код гораздо более понятным и поддерживаемым, кроме того оно защитит его от «благих намерений» тех, кто будет заниматься его поддержкой после вас.

29. Остерегайтесь «аналитического паралича». Помните, что нужно постоянно двигаться вперед в разработке, до тех пор, пока не станете знать о проекте все, и зачастую лучший и самый быстрый способ узнать что-нибудь о неучтенных факторах — это перейти на следующий этап, вместо того, чтобы пытаться сформулировать все мысленно. Вы не можете знать решения, пока не найдете его. Ваши ошибки в классе или множестве классов не разрушат целостности всей системы.

30. Когда вам кажется, что у вас все проанализировано, разработано или реализовано, проведите сквозной контроль. Позовите кого-нибудь извне вашей группы — это не должен быть консультант, а например, кто-нибудь из другой группы в вашей компании. Осмотр вашей работы свежей парой глаз может обнаружить проблемы на стадии, когда их легче устранить, и пользы от этого будет больше, чем затрат времени и средств.

Задание: Спроектировать DOM и построить диаграмму классов для слоя бизнес-логики «информационной системы текущей успеваемости учащихся». Общее описание: Система выводит текущие оценки выбранного учащегося по выбранному предмету и вычисляет средний балл. Оценки вносит преподаватель, читающий указанный предмет.

1. Основное задание:

1.1. Составить перечень классов объектной модели предметной области.

1.2. Определить отношения между классами.

1.3. Определить возможные состояния (список атрибутов) классов.

1.4. Определить поведение (список методов) классов.

1.5. На основе диаграммы классов предметной области построить диаграмму реализации (диаграмму классов с указанием полей и методов).

1.6. Дать оценку модели с точки зрения соответствия основным принципам проектирования.

2. Дополнительные задания:

2.1. Создать каркас кода для полученной модели на языке С++.

2.2. Создать модель хранения данных (если необходимо) для построенной DOM.

2.3. Описать пример класса Data-mapper для слоя ORM между моделью хранения данных и DOM.