Диаграмма классов.
Архитекторы программного обеспечения разговаривают на языке UML. Это такая своеобразная программисткая латынь. Использовать UML напрямую для программирования неудобно, зато многие его понимают и используют для выписывания рецептов описания архитектуры системы. Нарисовал диаграмму классов и стало понятней что к чему. Её поймет и дельфист и жаваист, и сишник и питоньшик, и сишарпер и рубист (вобщем все кто изучал ООП).
Центральное место в UML занимают диаграммы классов. Это букварь. В интернете можно найти огромное количество информации о диаграммах классов (структура, обозначение классов, интерфейсов, атрибутов, отношений и т.д. ), но при этом относительно мало информации о том, как осуществлять сам процесс проектирование. В этой связи хотел обратить внимание читателя на два особых момента.
От общего к частному…
Самое главное при создании диаграммы классов использовать принцип “от общего к частному”. На самом деле это один из фундаментальных принципов, который великие художники прошлого открыли уже много лет назад.
Представим, что Вы не умеете хорошо рисовать, но вам очень хочется нарисовать например чью-то голову. Вы берете карандаш, кладете лист бумаги и начинаете рисовать его левый глаз. Потратив на этот несчастный левый глаз больше часа, Вы беретесь за нос, затем за правый глаз, ухо и только потом пытаетесь дорисовать все остальное. Вполне вероятно, что итог работы Вас опечалит (не советую показывать жертве результат работы) – глаз, нос, рот и уши будут не на своем месте. Конечно, бывают среди нас гении, у которых получится шедевр, но все-таки, те, кто занимается этим профессионально проповедуют другой подход – “От общего к частному, от частного к общему”. Вначале делается эскиз, “топорный” рисунок. Затем дальнейшая проработка. Например так:
Точно так же я советую поступать в работе с диаграммами классов в UML. Мы создаем эскиз. Выделяем основные классы, определяем отношения между ними, затем прорабатываем мультипликаторы, поля, методы и их область видимости, сигнатуру вызовов, вспомогательные классы и так далее…
Но начинать нужно с формирования набора базовых классов. Для этого нужно просто нарисовать прямоугольники и написать в них имена основных классов. Затем постепенно прорабатывать все остальное.
Например так:
-
этап 1 -
этап 2 -
этап 3 -
этап 4
Кстати, если вы владеете техникой кунг-фу “UML colors” от мастера Кода, то можно начать использовать её уже на первом этапе.
Теперь давайте приступим к исследованию другого фундаментального вопроса в архитектуре ПО.
Быть или иметь?
Существуют два фундаментальных отношения “быть” и “иметь”. Самое грубое и примитивное объяснение: “быть” – наследование, “иметь” – агрегация (см. справочник). Казалось бы, какая разница? В некоторых языках это вообще одно и тоже слово.
Например: “У меня есть телефон” (иметь, обладать) и “Телефон есть орудие общения” (быть, являться).
На самом деле разница огромная. Представим что у нас есть класс User, который определяет некоторого пользователя системы. Пользователи бывают разные: анонимный пользователь или гость, редактор статей и администратор. Как определить эти сущности?
Можно сделать так:
А можно сделать так:
В первом случае у нас отношение “быть, являться”. Любой из объектов класса Admin, Editor, Guest также является пользователем (is a User).
Во втором случае отношение “иметь”. Объект класса User, имеет некоторое свойство-атрибут (has a), которое определяет статус этого пользователя в системе. Проецируя на реальный мир, мы должны задуматься “кто такой наш пользователь?”. Что значит для него “быть админом“? Если это нечто неотделимое от него самого, его внутренней сути, сущностного Я, его Identity, если наш пользователь рожден админом и уходит в другой мир админом, то тогда “Admin is a User” вполне оправдано.
Но если “админ” это всего лишь ярлык, некая роль, должность или социальный статус, обладание которым облегчает или усложняет жизнь нашему пользователю и при этом мы отлично знаем, что “высшие силы” всегда могут в любой момент лишить его админских сверхспособностей, то тогда, возможно, второй вариант будет более правильным.
В первом случае админ-пользователь гордо кричит “Я есть админ!” и этого у него не отнять, то во втором он скромно говорит: “У меня есть статус админа”.
Таким образом отвечая на вопрос “быть или иметь?”, мы задаем базовые отношения в нашей системы и нужно хорошо подумать, прежде чем рисовать стрелочки между классами.
P.S.: рисунки головы взяты с сайта http://jivopisets.ru/risunok-golovy-s-zhivoi-modeli.html