Как я могу применить шаблоны проектирования в этой ситуации?

Question

Ситуация: предположим, что мы разрабатываем пользовательский интерфейс Windows 9 с использованием Java API. Нам необходимо создать 3 класса main, BuildInWindow и ApplicationWindow.

main - окно для визуализации пользовательского интерфейса системы (т.е. начала Боттона & обоев страница)

BuildInWindow - окон для рендеринга buildt в приложениях (например, IE)

ApplicationWindow - окна для визуализации приложений из третья сторона (например, затмение)

все они должны реализовать 3 интерфейсы API Java, WindowFocusListener, WindowListener и WindowStateListener и имеют методы onExit() и onCrushing().

onExit() выполняет, когда система/встроенные приложения/третьи стороны приложения отключается нормально

onCrushing() фиксирует любую систему/давку и отправить состояние системы обратно на сервер

Это оригинальный дизайн :

http://i.stack.imgur.com/JAJiY.png

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

1. Создание abstract class методом onExit() и onCrushing(). Так как код onExit() будет варьироваться от 3-х классов, это должно быть abstract method & onCrushing() будет же Ф.О. всех классов, так что это будет конкретный метод
2. MAIN ОКНО должны использовать singleton дизайн, чтобы обеспечить пользователю создать только один экземпляр main.
3. Используйте facade дизайн избавляет от реализации 3 интерфейса для трех классов

Моего вопроса я не очень понимаю, дизайна фасада, так что я не уверен, что он может быть применен в данном случае. Также я не уверен, что onExit() будет отличаться для 3 классов, а onCrushing() будет выполнять ту же функцию.

Я пробовал изо всех сил, чтобы четко объяснить вопрос ... если вы не понимаете, что свободно комментировать. Большое спасибо!

Answer 1

Я оставил некоторые вопросы в комментариях, связанных с вашим вопросом, но вот некоторые рекомендации для вас:

1. Вы не должны создать абстрактный класс, на основе как BuildInwindow и ApplicationWindow как имеющий в имеют методы #onExit и #onCrushing, если они не могут использовать какую-либо реализацию. Абстрактные классы наиболее полезны там, где существует общая реализация. Интерфейса, содержащего эти методы, было бы достаточно. Тем не менее, ваши два окна могут совместно использовать другие функции, и если это так, их можно было бы распространять через общий суперкласс (абстрактный, если он опирается на детали реализации подкласса).Вы можете найти шаблон Template Method, полезный для управления общим механизмом окна с конкретным пошивом для разных типов окон. Вы также можете найти способ создания экземпляра Factory Method (для ваших оконных классов), который поможет отделить создание и настройку объекта от механизма создания.

2. Один общий экземпляр представляется разумным, и одноэлемент будет служить этой цели (до тех пор, пока вы сможете обрабатывать завершение и т. Д.). Кроме того, ваше приложение может просто запустить один экземпляр Main - вы даже можете просто скрыть конструктор через доступ к пакету, чтобы убедиться, что другие не созданы.

3. Шаблон фасада просто упрощает сложный интерфейс. В основном это происходит, переходя звонки на совместные экземпляры вместе под одним (более грубым) интерфейсом. Обычно это не было сделано, чтобы скрыть интерфейсы, поддерживаемые классом. Действительно, публикация, которая взаимодействует с расширением класса, важна для пользователей API. Вы можете свернуть три интерфейса в один интерфейс для «удобства», но я думаю, что это не нужно. Если вы соглашаетесь на общий суперкласс, то это будет «расширять» три интерфейса (если бы все подклассы ожидали их поддержки). Он также может реализовать некоторую стандартную реализацию этих интерфейсов (опять же, наблюдайте за модификаторами доступа, чтобы гарантировать, что те, кого вы намереваетесь быть, могут быть переопределены, а другие могут быть окончательными).

Edit: Руководство

Вы просто должны определить классы и отношения: Я предлагаю вам просто взять какую-то бумагу и рисовать. У вас уже есть свои существительные и глаголы (в противном случае вы можете использовать определение существительных и глаголов для определения классов и методов на них).

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

Далее уточните диаграмму, чтобы начать перемещение общих функций в одно место (абстракция). Вы знаете, что это существует в отношении ваших интерфейсов и методов, которые вы предлагаете, но вам может понадобиться решить, какие (если таковые имеются) имеют общие функции. Затем определите, удовлетворяет ли интерфейсы вашим потребностям (методы распространены, но реализации различны), или если сама реализация одинакова и поэтому может быть полезен родительский суперкласс (это абстрагирует [кто несет ответственность за что], инкапсуляция [отдельные реализации на соответствующий уровень] и полиморфизм [классы, которые поддерживают общие методы]). Обратите внимание, что даже если вы соглашаетесь на суперкласс, вам было бы разумно поддержать его с помощью интерфейса (это облегчает вовремя введение классов для братьев и сестер - подумайте об обслуживании).

Далее, работа над проблемами, которые вы нашли. Ваш проект проекта прояснил любой из них? Например, ваш Main должен знать о своих окнах, но какой тип они? Итак, имеет ли какое-либо из ваших уточнений это яснее?

Есть ли у вас какие-либо образцы? для этого вам нужно уже почувствовать модели дизайна, я боюсь, поэтому покупаю и поглощаю GoF Design Patterns book. Это положит вас на то, чтобы найти образцы, как вы идете. Я также рекомендовал бы прочитать эту конкретную книгу, прежде чем принимать какие-либо другие, так как это технологическая агностика (и некоторые другие книги разбросаны с техническими обходными решениями). Возможно, изучите два шаблона, на которые я указал, и посмотрим, соответствуют ли они вашим требованиям.

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