Введение в объектно-ориентированный дизайн с Java - стр. 4

Например, компонент тренажерного зала потребует дополнительных компонентов, таких как пол.

Пол будет отвечать за поддержание большого веса.

Домовладелец тренируется как олимпийский атлет.

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

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

И при создании приемлемого решения могут возникнуть компромиссы.

Что делать, если укрепление пола в спортзале требует помещения колонн или балок в подвал под тренажерный зал?

И что, если домовладелец также хочет иметь широкое открытое пространство в подвале с хорошей комнатой отдыха?

Иногда могут возникать такие конфликты.

Вам и домовладельцу необходимо будет выработать компромисс в решении.

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

Затем технические диаграммы становятся основой для построения предполагаемого решения.

Компоненты, когда они достаточно проработаны, превращаются в коллекции функций, классов или других компонентов.

Эти части представляют собой гораздо более простую проблему, которую разработчики могут реализовывать индивидуально.

Когда вы разделяете объекты на более мелкие объекты, вы можете обнаружить, что вы будете идентифицировать разные типы объектов.

И обычно определяют три категории объектов.

Во-первых, это Entity объекты.

Entity объекты наиболее знакомы, потому что они соответствуют некоторому реальному объекту.

Если у вас есть объект, представляющий стул в вашем программном обеспечении, то это Entity объект.

Если у вас есть объект, представляющий здание или клиента, это все Entity объекты или сущности.

Как правило, эти объекты знают свои атрибуты.

Они также смогут модифицировать себя и иметь для этого некоторые правила.

Когда вы идентифицируете объекты для включения в ваше программное обеспечение и разбиваете эти объекты на более мелкие объекты, вы сначала получаете Entity объекты.

Другие категории объектов приходят позже, когда вы начнете думать о техническом дизайне программного обеспечения.

Далее, это Boundary объекты.

Граничные объекты Boundary – это объекты, которые находятся на границе между системами.

Это может быть объект, который соприкасается с другой программной системой, например, объект, который получает информацию из Интернета.