Шаблоныобъектно-ориентированногопроектированияgrasp — КиберПедия 

Индивидуальные очистные сооружения: К классу индивидуальных очистных сооружений относят сооружения, пропускная способность которых...

История развития хранилищ для нефти: Первые склады нефти появились в XVII веке. Они представляли собой землянные ямы-амбара глубиной 4…5 м...

Шаблоныобъектно-ориентированногопроектированияgrasp

2017-11-17 350
Шаблоныобъектно-ориентированногопроектированияgrasp 0.00 из 5.00 0 оценок
Заказать работу

 

GRASP - General Responsibility Assignment Software Patterns (основные шаблоны распределения обязанностей в программном обеспечении). Это методический подход к объектному проектированию. Эти шаблоны называют также шаблонами распределения обязанностей. Под "шаблоном" в данном контексте, да и в любом контексте, связанном с разработкой ПО, понимается именованная пара "проблема/решение", содержащая рекомендации для применения в различных конкретных ситуациях. Шаблоны GRASP относятся к этапу проектирования и отвечают за взаимосвязь объектов в системе. GRASP состоит из 5 основных и 4 дополнительных шаблонов.

 

Основные шаблоны:

· Information Expert

· Creator

· Controller

· Low Coupling

· High Cohesion

 

Дополнительныешаблоны:

· Pure Fabrication

· Indirection

· Polymorphism

· Protected Variations

· Information Expert

 

Шаблон решает проблему распределения обязанностей между объектами в объектно-ориентированной системе. Под обязанностью в контексте GRASP понимается некое действие (функция) объекта. Т.о. Information Expert дает рекомендации касательно того, какие функции должен выполнять тот или иной объект. А решение очень простое и понятное без доказательств: назначать обязанность следует информационному эксперту - классу, у которого имеется информация, требуемая для выполнения обязанности. Конечно, не всегда бывает так, что вся необходимая информация заключена в одном классе (это, кстати, идет в противоречие с паттерном High Cohesion, о котором позже), чаще она распределена между различными классами, тогда каждый из этих классов будет являться частичным экспертом, т.е. будет предоставлять только доступную ему информацию, а при общем взаимодействии будет решена общая задача.

 

Creator

Шаблон Creator решает проблему о том, кто должен создавать экземпляры новых классов. Решение состоит в назначении классу B обязанностей создавать экземпляры класса A, если выполняется одно из условий:

Класс B агрегирует (aggregate) объекты A

Класс B содержит (contains) объекты A

Класс B записывает (records) экземпляры объектов A

Класс B активно использует (closely uses) объекты A

Класс B обладает данными инициализации (has the initializing data), которые будут передаваться объектам A при их создании (т.е. при создании объектов А класс В является экспертом)

Смысл паттерна снова интуитивно понятен, каждый разработчик использовал его, руководствуясь здравой логикой, сам того не осознавая. Тем не менее, за кажущейся простотой скрывается масса преимуществ: поддерживается шаблон Low Coupling, снижаются затрат на сопровождение и обеспечивается возможности повторного использования созданных компонентов в дальнейшем.

 

Controller

Шаблон сontroller решает давнюю проблему разделения интерфейса и логики в интерактивном приложении. Это не что иное, как C из аббревиатуры MVC. Этот шаблон отвечает за то, к кому именно должны обращаться вызовы из V (View), и кому C должен делегировать запросы на выполнение (какая модель M должна их обработать). Если обобщить назначение сontroller, то он должен отвечать за обработку входных системных сообщений. Под системными сообщениями здесь понимаются события высокого уровня, генерируемые внешним исполнителем. Чтобы решить поставленную проблему необходимо делегировать обязанности обработки системных сообщений классу, удовлетворяющему одному из следующих условий:

Класс представляет всю систему в целом, устройство или подсистему (внешний контроллер)

Класс представляет сценарий некоторого прецедента, в рамках которого выполняется обработка всех системных событий, и обычно называется <Прецедент>Handler, <Прецедент>Coordinator или <Прецедент>Session (контроллер прецедента или контроллер сеанса). Для всех системных событий в рамках одного сценария прецедента используется один и тот же класс-контроллер. Неформально, сеанс - это экземпляр взаимодействия с исполнителем. Сеансы могут иметь произвольную длину, но зачастую организованы в рамках одного прецедента (сеанса прецедента).

Как бы заумно не звучало все вышеперечисленное, на самом деле все предельно просто: контроллер это своеобразный вид интерфейса между уровнями предметной области и графического представления. Первым типом контроллеров является внешний контроллер (facade controller), представляющий всю систему, устройство или подсистему. Если применяется контроллер прецедента (use case controller), то для каждого прецедента должен существовать отдельный контроллер. Не объект предметной области, а искусственная конструкция.

 

Low Coupling

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

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

Высокая степень связывания сама по себе не является проблемой. Проблемой является жесткое связывание с неустойчивыми в некотором отношении элементами.

 

High Cohesion

Шаблон решает общую проблему управления сложностью за счет регулирования степени зацепления классов. Разница между связностью и зацеплением очень тонка, и понять ее необходимо на более глубоком интуитивном уровне. Зацепление (cohesion) (или более точно, функциональное зацепление) - это мера связанности и сфокусированности обязанностей класса. Считается, что элемент обладает высокой степенью зацепления, если его обязанности тесно связаны между собой и он не выполняет огромных объемов работы. Класс с низкой степенью зацепления выполняет много разнородных функций или несвязанных между собой обязанностей.

High Cohesion твердит, что класс должен стараться выполнять как можно меньше не специфичных для него задач, и иметь вполне определенную область применения. Только с опытом приходит понимание балансировки между High Cohesion и Low Coupling. считается что связывание и зацепление это инь и янь проектирования ПО. Некорректное связывание порождает неправильное зацепление и наоборот.

 

Pure Fabrication

Формулировки и мотивации дополнительных шаблонов GRASP не так очевидны. И без примеров здесь трудно ориентироваться. Проблемой, решаемой Pure Fabrication, является обеспечение реализации шаблонов High Cohesion и Low Coupling или других принципов проектирования, если шаблон Expert (например) не обеспечивает подходящего решения. Решением может быть введение служебного класса, не представляющего понятия конкретной предметной области, однако имеющего высокую степень зацепления.

Например, классу X необходимо сохранять информацию в реляционной базе данных. Согласно шаблону Information Expert, эту обязанность можно присвоить самому классу X. Однако следует принять во внимание, что Данная задача требует достаточно большого числа специализированных операций, поэтому класс X будет иметь низкую степень зацепления, класс X будет связан с интерфейсом БД, что повысит связность, кроме того задача записи в БД является довольно общей, поэтому необходимо обеспечить повторное использование кода. Естественным решением данной проблемы является создание нового класса, ответственного за сохранение объектов некоторого вида на постоянном носителе, например, в реляционной базе данных. Его можно назвать PersistentStorage. Это чисто синтетический объект, что полностью соответствует Pure Fabrication. В итоге решаются задачи зацепления, связности и повторного использования.

 

Indirection

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

Пример, рассмотренный выше, с введением класса PersistentStorage является также и примером шаблона Indirection, т.к. дополнительный класс будет являться промежуточным звеном между БД и классом X. Примерами специализированных вариантов Indirection являются шаблоны Adapter, Facade, Observer (см. шаблоны Gang of Four). Целью введения промежуточного звена является обеспечение слабой связности за счет отделения друг от друга различных компонентов.

 

Polymorphism

Принцип полиморфизма является основополагающим в ООП. В данном контексте шаблон Polymorphism решает проблему обработки альтернативных вариантов поведения на основе типа. Решать эту проблему стоит с использование полиморфных операций, а не с помощью проверки типа и условной логики. Кроме того, при помощи полиморфизма легко создавать подключаемые компоненты. В итоге получаем следующие преимущества:

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

Новые вариации можно вводить без модификации клиентской части приложения.

 

Protected Variations

Основная проблема, решаемая шаблоном Protected Variations: как спроектировать объекты, подсистемы и систему, чтобы изменение этих элементов не оказывало нежелательного влияния на другие элементы? необходимо идентифицировать точки возможных вариаций или неустойчивости; распределить обязанности таким образом, чтобы обеспечить устойчивый интерфейс. Шаблон PV описывает ключевой принцип, на основе которого реализуются механизмы и шаблоны программирования и проектирования с целью обеспечения гибкости и защиты системы от влияния изменений внешних систем.

Инкапсуляция данных, интерфейсы, полиморфизм, перенаправление - все эти принципы реализуются в рамках шаблона PV. Существует много принципов проектирования, которые тем или иным образом являются проявлением этого шаблона:

Проектирование на основе данных

Поиск служб

Проектирование на основе интерпретаторов

Рефлексивное проектирование или проектирование на метауровне

Унифицированный доступ

Каким бы ни был способ реализации, неизменным остается базовый принцип шаблона: обеспечить устойчивость интерфейса.

 


 

Информационная база проекта

 

База данных— это совокупность таблиц, отношений между таблицами, индексов, триггеров и хранимых процедур. База данных обычно является частью программного проекта и используется для хранения разнообразной информации. Сюда включаются данные о самой программе, её настройках, пользователях с их логинами и паролями, информационные и справочные ресурсы приложения.

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

На данный момент существует достаточное большое многообразие баз данных, различающихся по типологии и разработчикам. Рассмотрим наиболее часто встречающиеся БД и технологии доступа к ним.

BDE (сокр. от англ. BorlandDatabaseEngine — «движок баз данных Borland») — 32-битный движок баз данных под MicrosoftWindows для доступа к базам данных из BorlandDelphi, C++ Builder, IntraBuilder, ParadoxforWindows и VisualdBASEforWindows на локальной машине. BDE имеет объектно-ориентированное устройство. Во время выполнения приложение взаимодействует с BDE, создавая различные BDE-объекты. Эти объекты затем используются для управления элементами БД, такими как таблицы и запросы. BDE API даёт прямой и оптимизированный доступ к движку, а также к встроенным в BDE драйверам. В поставку BDE входит набор дополнительных утилит и примеров приложений.Система BDE конфигурируется с помощью BDE Administrator (BDEADMIN.EXE).

ADO (от англ. ActiveXDataObjects — «объекты данных ActiveX») — интерфейс программирования приложений для доступа к данным, разработанный компанией Microsoft (MSAccess, MSSQLServer) и основанный на технологии компонентов ActiveX. ADO позволяет представлять данные из разнообразных источников (реляционных баз данных, текстовых файлов и т. д.) в объектно-ориентированном виде. Объектная модель ADO состоит из следующих основных объектов высокого уровня:

· Connection (представляет подключение к удалённому источнику данных)

· Recordset (представляет набор строк, полученный от источника данных)

· Command (используется для выполнения команд и SQL-запросов с параметрами)

· Record (может представлять одну запись объекта Recordset)

· Fields (представляет столбцы таблицы базы данных)

Компоненты ADO используются в языках высокого уровня, таких как ASP, JScript в WSH, Visual Basic, Delphi.

Interbase — реляционная система управления базами данных, разрабатывающаяся в данный момент компанией Embarcadero, появилась в середине 1980-х годов, принадлежала самостоятельной одноимённой компании, Ashton-Tate отBorland. С развитием и поддержкой Interbaseу Borlandбыли трудности. Некоторое время она вообще не поддерживалась. 31 июля 2000 года инициативная группа в которую входили первоначальные разработчики Interbase, отчаявшись добиться от Borland поддержки или хотя бы внятной позиции, скопировала исходные коды Interbase 6 и образовала проект Firebird — свободный проект, основанный на кодах Interbase 6 Open Source, активно развивающийся независимо.

MySQL — свободная реляционная система управления базами данных. Разработку и поддержку осуществляет корпорация Oracle, получившая права на торговую марку вместе с поглощённой SunMicrosystems. Продукт распространяется как под бесплатной GNU, так и под собственной коммерческой лицензией. Помимо этого, разработчики создают функциональность по заказу лицензионных пользователей. Именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.MySQL является решением для малых и средних приложений. Входит в состав серверов LAMP, Денвер, XAMPP. Обычно MySQL используется в качестве сервера баз данных для сайтов.Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Управление СУБД осуществляется через браузер.

MicrosoftAccess — реляционная система управления базами данных (СУБД)[1] корпорации Microsoft. Входит в состав пакета MicrosoftOffice. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных. Содержит ряд мастеров для упрощения построения таблиц, отчётов, запросов и прочего. Microsoft Jet Database Engine (англ.), которая используется в качестве движка базы данных MS Access является файл-серверной СУБД и потому применима лишь к приложениям, работающим с небольшими объёмами данных и при небольшом числе пользователей, одновременно работающих с этим данными. Непосредственно в Access отсутствует ряд механизмов, необходимых в многопользовательских базах данных, таких, например, как триггеры.

SQLite — компактная встраиваемая реляционная база данных.Слово «встраиваемый» (embedded) означает, что SQLite не использует парадигму клиент-сервер, то есть движок SQLite предоставляет библиотеку и становится составной частью программы. Таким образом, в качестве протокола обмена используются вызовы функций (API) библиотеки SQLite. Такой подход уменьшает накладные расходы, время отклика и упрощает программу. SQLite хранит всю базу данных (включая определения, таблицы, индексы и данные) в единственном стандартном файле на том компьютере, на котором исполняется программа.Сама библиотека SQLite написана на C; существует большое количество привязок к другим языкам программирования, в том числе Delphi, C++, Java, C#, VB.NET, Python, Perl, Node.js, PHP, PureBasic, Tcl, Ruby, Haskell, Scheme, Smalltalk, Lua и Parser, а также ко многим другим.Многие программы поддерживают SQLite в качестве формата хранения данных: 1С:Предприятие 7.7; AdobePhotoshopLightroom;AIMP; Google Chrome; Opera; Safari; Oracle; FireDAC и др.

 

Помимо хранения данных программы, при её эксплуатации у пользователя есть ещё потребность в хранении у разработчика. Такую базу обычно называют репозиторий.

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

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

Существуют репозитории для хранения программ, написанных на одном языке (например, CPAN для Perl) или предназначенных для одной платформы. Многие современные операционные системы, такие как OpenSolaris, FreeBSD и большинство дистрибутивов Linux, имеют официальные репозитории, но также позволяют устанавливать пакеты из других мест. Большинство репозиториев бесплатны, однако некоторые компании предоставляют доступ к собственным репозиториям за платную подписку.

Русское сообщество Subversion рекомендует использовать вместо термина репозиторий термин хранилище, поскольку он полностью соответствует как прямому переводу слова «repository», так и его понятию.

 


 


Поделиться с друзьями:

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

Особенности сооружения опор в сложных условиях: Сооружение ВЛ в районах с суровыми климатическими и тяжелыми геологическими условиями...

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

История развития пистолетов-пулеметов: Предпосылкой для возникновения пистолетов-пулеметов послужила давняя тенденция тяготения винтовок...



© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!

0.008 с.