Шаблоны распределения ответственности

Задание: Разработайте приложение-игру пасьянс, позволяющее раскладывать один из карточных пасьянсов (см. свой вариант). Приложение должно выполнять первоначальный расклад, давать пользователю возможность совершать ход (проверяя, является ли он корректным), проверять, есть ли ещё возможные ходы для пользователя, а также выдавать сообщение о том, что пасьянс сошёлся или не сошёлся. При проектировании структуры приложения используйте следующие шаблоны распределения ответственности: информационный эксперт; создатель; контроллер; слабая связанность; сильное зацепление. Процесс проектирования проиллюстрируйте UML-диаграммами классов и состояний. Вариант: Карлтон. Указания: В данной лабораторной работе предполагается изучение основ шаблонов проектирования GRASP (General Responsibility Assignment Software Patterns). Рассматривается лишь пять основных шаблонов. Шаблон «информационный эксперт» принято первым применять при проектировании сложных систем. Основная цель этого шаблона выделить классы, которые будут хранить информацию, и классы, которые будут ее обрабатывать. Под обработкой понимается не только работа алгоритмов, реализующих основную логику приложения, но и взаимодействие (добавление, чтение, изменение, удаление данных) с системой хранения данных, а также визуализация данных, проверка их корректности и т.д. Таким образом, согласно данному шаблону необходимо выделить классы, являющиеся информационными экспертами. Поля таких классов хранят нужную информацию, а методы лишь предоставляют к ней доступ (зачастую это просто методы чтения и записи значений данных полей). После того, как информационные эксперты выделены, эти классы не реализуют никакой логики обработки хранимой информации (даже проверку на корректность данных). Для реализации логики используются другие классы, которые будут обрабатывать данные, хранимые информационными экспертами. По большому счету, все остальные шаблоны регламентируют распределение ответственности между этими оставшимися классами. Шаблон «сильное зацепление» используется при разделении обязанностей между всеми классами и регламентирует количество задач, возлагаемых на каждый класс. Данный шаблон практически полностью повторяет принцип единственной ответственности. Единственное различие принципа единственной ответственности и шаблона проектирования «сильное зацепление» в том, что принцип единственной ответственности формулируется исходя из цели проектирования (обеспечение гибкой расширяемости приложения), а шаблон проектирования «сильное зацепление» способ достижения этой цели – максимальная конкретизация поставленной перед классом задачи. Один из признаков нарушения этого шаблона – название класса, не вполне адекватно отражающее то, что данный класс делает. Шаблон «слабая связанность» также используется при разделении обязанностей между всеми классами, но регламентирует он количество связей класса с другими классами. Согласно данному шаблону проектирования при проектировании классов нужно стараться минимизировать его связи с другими классами. Практически, этот шаблон декларирует еще один способ соблюдения принципа единственной ответственности. Также этот шаблон связан с шаблоном «сильное зацепление». Действительно, если класс имеет четко обозначенный круг обязанностей (то есть «сильно зацеплен» за свои обязанности), то для решения этих задач ему достаточно минимального количества связей с другими классами. Явными признаками связи между класса являются: наследование; реализация интерфейса; наличие в классе поля-ссылки на другой класс; наличие в классе метода, принимающего в качестве параметра ссылку на другой класс; наличие в классе метода, возвращающего в качестве результата ссылку на другой класс; наличие в методе класса локальной переменной-ссылки на другой класс. Для ослабления некоторых зависимостей может использоваться другой шаблон – «создатель». Следует, однако, заметить, что зависимости между информационными экспертами и другими классами, как правило, не учитываются. Это происходит от того, что информационные эксперты используются для транспорта информации от одних классов, реализующих обработку данных, другим. Точнее было бы сказать, что не учитывается степень связанности информационного эксперта с другими классами, но для этих классов связи с информационными экспертами могут учитываться. Хотя в такой ситуации проще использовать шаблон «сильное зацепление». А вот степень связанности нескольких информационных экспертов – важный показатель, так как от этого зависит простота расширения предметной области. Но зачастую основным фактором при моделировании предметной области все же является не шаблоны «сильное зацепление» или «слабая связанность», а адекватность создаваемой модели. Шаблон «создатель» и «контроллер» используется при распределении определенного рода обязанностей. Шаблон «создатель», в частности, – это класс, который берет на себя ответственность за создание (инстанцирование) экземпляра некоторого класса (как правило не информационного эксперта). Чаще всего методы класса-создателя возвращают ссылку на созданный объект, инкапсулируя процесс создания и инициализации этого объекта. В общем случае классом-создателем можно назвать любой класс, который неким образом создает любой объект. Так, например, класс, который читает некоторую информацию из файла, а затем создает на основе этой информации объект информационного эксперта (или список таких объектов) и возвращает ссылку на этот объект, уже можно назвать создателем. Шаблон «контроллер» – это класс, который берет на себя ответственность взаимодействия с внешними по отношению к системе факторами. Чаще всего это взаимодействие с пользователем, но также это может быть обработка некоторых событий, возникающих в определенное время, или обработка сигналов, приходящих с различных датчиков. Мы будет рассматривать только контроллеры, обрабатывающие пользовательские запросы. Такие контроллеры условно можно разделить на две группы: единая точка входа (Front Controller); контроллер прецедента (Page Controller). К первой группе относятся контроллеры, которые обрабатывают абсолютно все запросы пользователя, извлекают из такого запроса все необходимые данные, принимают решения, кому перенаправить этот запрос для обработки, после чего либо обработка запроса заканчивается (то есть часть системы, которой передали запрос на обработку, выполнила все необходимые действия и сама сообщила пользователю о результатах), либо контроллер может принимать результат обработки запроса и сообщать его пользователю. Такие контроллеры удобно использовать при создании сетевых серверов, получающих запросы от клиента по некоторому прикладному протоколу (HTTP, FTP и т.д.); при создании настольных приложений с использованием непосредственно Windows API (при наличии единой оконной функции для приложения); при разработке консольных приложений, работающих в командном режиме (когда пользователь сначала полностью набирает текст команды, которая содержит всю необходимую информацию, а затем ее обрабатывает, как, например, консольный клиент для MS SQL Server). Ко второй группе относятся контроллеры, которые обрабатывают специализированные запросы (например, запрос на создание новой записи в базе данных обрабатывает один контроллер, а запрос на удаление записи – другой). Такие контроллеры удобно использовать при разработке web-приложений, работающих под управлением стандартного web-сервера (Apache, Small HTTP Server, и т.д.). В таком случае общую обработку запроса осуществляет сам web-сервер, а затем вызывается определенная часть нашего приложения (например, определенный PHP-скрипт). Также такие контроллеры удобно использовать в настольных приложений с использованием высокоуровневых библиотек (VCL, MFC или QT для C++; AWT, Swing или SWT для Java и т.д.). В таком случае один обработчик некоторого события (нажатия на кнопку, выбора элемента из списка и т.д.) является отдельным контроллером. Еще подобные контроллеры используются при разработке консольных приложений, в которых пользователь сначала выбирает некоторое общее действие в меню, а затем в диалоговом режиме приложение уточняет нужные данные. Тогда каждому действию в меню ставится в соответствие свой контроллер, который затем начинает свой диалог с пользователем. Правила пасьянса «Карлтон» Пасьянс раскладывается колодой из 52 карт. Карты из колоды раскладываются на 4 стопки, в первой стопке 4 карты, во второй стопке 3 карты, в третьей стопке 2 карты, в четвертой стопке 1 карта. Карты в стопках раскладываются так, чтобы все карты в стопке были видны. Сверху над стопками располагаются 4 основания для собираемых карт. Рядом кладется колода с оставшимися картами. Перекладывать карты со стопки на стопку можно в нисходящей последовательности с чередованием цвета масти (например, на чёрного валета можно перекладывать красную десятку, с одной стопки на другую можно перекладывать сразу несколько карт, если они уже упорядочены в требуемом порядке). Также на пустую стопку можно переложить короля, или несколько карт с нижним королём. В основания сверху над стопками сначала кладутся тузы, а далее карты в восходящей последовательности: 2, 3, 4, 5, 6, 7, 8, 9, 10, валет, дама, король – все карты на основании должны быть одной масти. Когда карт для перекладывания нет, то на каждую стопку (даже если в ней уже нет ни одной карты) берётся по одной карте из колоды. Пасьянс сошелся, если все карты собраны на 4 основаниях.