Введение в объектно-ориентированный дизайн с Java
Шрифт:
Давайте рассмотрим, как может выглядеть объектно-ориентированное моделирование.
Рассмотрим, например, помещение для семинаров.
Первый объект, который мы идентифицируем, является сама комната.
В комнате есть такие детали, как номер комнаты и места для сидения.
Также мы можем идентифицировать объекты, которые содержатся в этой комнате.
Существует множество физических объектов, такие как стул, стол, проектор и белая доска.
Каждый из этих физических объектов может быть представлен
И существуют конкретные детали, связанные с каждым объектом.
Проектор имеет характеристики, связанные с его производительностью, такие как разрешение и яркость.
И объекты также могут иметь индивидуальные обязанности или поведение.
Например, проектор принимает видеопоток и отображает изображение.
Вы можете думать о разработке программного обеспечения как о процессе, который берет задачу и создает решение с помощью программного обеспечения.
И как правило, это итеративный процесс, при этом каждая итерация берет набор требований для реализации и тестирования и в конечном итоге создается полное решение.
Многие разработчики стремятся сразу кодировать, несмотря на то, что не полностью понимают, что программировать в первую очередь.
И погружение прямо в работу по реализации является основной причиной отказа проекта.
Если вы не хотите, чтобы ваши проекты потерпели неудачу, найдите время, чтобы сформировать требования и создать дизайн.
Вы не можете сделать их идеальными, но их важность для эффективного создания хорошего программного обеспечения не следует упускать из виду.
Выявление требований требует активного изучения видения клиента, задавая вопросы о проблемах, которые клиент, возможно, не рассмотрел.
Помимо выявления конкретных потребностей, нужно спрашивать о возможных компромиссах, которые клиент может принять в решении.
С четким представлением о том, что вы пытаетесь выполнить, далее вы можете обратиться к шаблонам дизайна и диаграммам.
Рассмотрим следующий сценарий.
Вас наняли, чтобы спроектировать дом.
Прежде чем приступить к закладке фундамента, вы должны сначала понять, чего хочет домовладелец.
Эта отправная точка известна как выявление требований.
Домовладелец хочет иметь тренажерный зал, санузел, три спальни и гостиную.
Выявление требований подразумевает не только выслушивание того, что говорит вам клиент, но и задавание вопросов для выяснения того, что клиент вам не сказал.
Например, это показалось вам странным, что в этом доме нет кухни?
Это было бы естественным вопросом.
Или все комнаты должны быть одинакового размера?
Насколько большой должен быть дом в целом?
И так далее.
После ответа на эти вопросы у вас теперь есть первоначальный набор требований, позволяющий начать думать о возможных
Проектная деятельность предполагает принятие требований и определение решения.
Эта деятельность включает в себя создание концептуального дизайна, а затем технического дизайна, что приводит к двум соответствующим видам артефактов, концептуальным макетам и техническим схемам.
Концептуальные макеты представляют то, как будут удовлетворены требования в целом.
На этом этапе вы фокусируетесь на дизайне дома, определяя основные компоненты и их соединения и откладывая технические детали.
И чем яснее концептуальный дизайн, тем лучше будут технические проекты.
После того, как концептуальные макеты завершены, настало время определить технические детали решения.
Из концептуального дизайна вы знаете все основные компоненты и их соединения и обязанности компонентов.
Описание того, как выполняются эти обязанности, является целью технического проектирования.
В техническом дизайне вы начинаете указывать технические детали каждого компонента.
Это делается путем разделения компонентов на более мелкие компоненты, которые достаточно специфичны для детального проектирования.
Например, компонент тренажерного зала потребует дополнительных компонентов, таких как пол.
Пол будет отвечать за поддержание большого веса.
Домовладелец тренируется как олимпийский атлет.
Разбивая компоненты все больше и больше на дополнительные компоненты, каждый из которых несет определенные обязанности, вы доходите до уровня, где вы можете сделать детальный дизайн конкретного компонента, например, описать, как укрепить пол.
Технические диаграммы выражают, как решать конкретные проблемы, подобные этой.
И при создании приемлемого решения могут возникнуть компромиссы.
Что делать, если укрепление пола в спортзале требует помещения колонн или балок в подвал под тренажерный зал?
И что, если домовладелец также хочет иметь широкое открытое пространство в подвале с хорошей комнатой отдыха?
Иногда могут возникать такие конфликты.
Вам и домовладельцу необходимо будет выработать компромисс в решении.
Если компоненты, их соединения и их обязанности в вашем концептуальном дизайне оказались невозможными в техническом дизайне, или не в состоянии удовлетворить требованиям, вам нужно будет вернуться к вашему концептуальному дизайну и переделать его.
Затем технические диаграммы становятся основой для построения предполагаемого решения.
Компоненты, когда они достаточно проработаны, превращаются в коллекции функций, классов или других компонентов.
Эти части представляют собой гораздо более простую проблему, которую разработчики могут реализовывать индивидуально.