Преимущества использования шаблонов проектирования

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

____________________________________

Шаблоны проектирования уже освещались на данном портале – подробнее читайте в специальной рубрике:

Шаблоны проектирования (паттерн, pattern) — это эффективные способы решения характерных задач проектирования, в частности проектирования компьютерных программ. Паттерн не является законченным образцом проекта, который может быть прямо преобразован в код, скорее это описание или образец для того, как решить задачу, таким образом чтобы это можно было использовать в различных ситуациях. Объектно-ориентированные паттерны зачастую показывают отношения и взаимодействия между классами или объектами, без определения того, какие конечные классы или объекты приложения будут использоваться.

Выгоды от использования шаблонов:

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

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

• Шаблоны проектирования, изученные должным образом, существенно помогают общему пониманию основных принципов объектно-ориентированного проектирования.

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

Основы UML. Виды диаграмм UML.

UML- унифицированный язык моделирования, стандартизованное средство визуализации структуры и функционирования программы посредством диаграмм. Набор различных диаграмм — наиболее важное средство UML.

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

Назначение UML — дать полное представление об архитектуре системы (статическое представление) и описать принципы ее работы (динамическое представление системы) путем построения соответствующих диаграмм.

Однако не следует рассматривать UML как средство разработки ПО, UML является всего лишь средством для иллюстрирования разрабатываемого проекта. Несмотря на возможность применения к любому типу языков, UML наиболее полезен в объектно-ориентированном программировании.

Основные положения объектно-ориентированного подхода:

1. объектно-ориентированный анализ

2. объектно-ориентированное проектирование

3. объектно-ориентированное программирование

ООП является способом организации программы. Основное внимание при его изучении уделяется организации программы, а не вопросам написания кода.

3 основы ООП:

1. инкапсуляция (наполнение класса атрибутами и операциями);

2. наследование (отношение м/у классами, при котором класс использует структуру или поведение другого класса);

3. полиморфизм (изменение поведения объекта в зависимости от его типа).

Т.о. главным компонентом оо-программы является объект, содержащий данные и функции для их обработки. Класс является формой и образцом для множества сходных между собой объектов. Механизм наследования позволяет создавать новые классы на основе существующих классов, не внося изменения в последние. Порожденный класс наследует все данные и методы своего родителя, но имеет также свои собственные.

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

Фазы моделирования:

1. начальная (inception) — сбор информации и разработка базовых концепций — документация, диаграммы use case;

2. уточнения (elaboration) — определение архитектуры, анализ и проектирование, планирование тестов и кодировки — прототипы, диаграммы взаимодействия; в итоге получаем software requirement specification; уточнение предварительных оценок 1-го этапа (сроки, стоимость, модели use case); построение диаграмм последовательностей, классов и состояний; фаза пройдена, когда все спроектировано, рассмотрено; после этого этапа система передается разработчикам;

3. конструирования (construction) — написание основного кода — для любой операции идет разработка и тестирование; генерируется скелетный код; разработку и планирование тестов можно вести параллельно; осуществляется экспертная оценка кода; строится диаграмма компонентов

4. ввод в действие — получаем финальную версию; проводим тестирование; составляем документацию; обновляются модели способом обратного реинжиниринга.

1-я фаза — однократная, остальные — итерационные.

Виды диаграмм:

1. д классов (для статического представления архитектуры системы);

2. д объектов (показывает работу системы в любой момент времени, отображает объекты и взаимосвязи между ними);

3. д вариантов использования (возможные варианты работы с системой с отображением ее функций и пользователей);

4. д взаимодействия (взаимодействие компонентов системы между собой; д последовательностей и д кооперации);

5. д состояний (отображает состояние объекта в процессе работы системы в виде автомата);

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

7. д компонентов (показывает организацию набора компонентов и зависимости между ними; обеспечивает статическое представление системы и связана с д классов, т.к. размещает классы по компонентам (модулям) );

8. д пакетов;

9. д развертывания (позволяет отобразить механизмы конфигурирования системы, ее внедрения и сопровождения)

________________________________________

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

Если я и могу вам сделать добро, то наве…

Если я и могу вам сделать добро, то наверно только такое (кстати все 2008 года):

1. The Productive Programmer — Neal Ford — много всего интересного причем не только для дотнэтчиков (ненавижу писать это слово), но и джавистов и макосников.

  

the-productive-programmer-theory-in-practice.9780596519780.34002.pdf

2. C# 3.0 Design Patterns — Judith Bishop — классика на новый лад.

c-3-0-design-patterns.pdf

3. Code Leader Using People, Tools, and Processes to Build Successful Software — Patrick Cauldwell — все винтики разобраны…интересная книжка и дотнэт там мало причем…

code-leader-using-people-tools-and-processes-to-build-successful-software-programmer-to-programm.pdf

Кстати я тут подсел на Бира и Мизеса, на очереди Ландау и может быть Эшби, и Оуэн вроде…серьезно…прикольные мужики…расскажу как-нить =)))

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

А иконки клевые да…Box.net сам типа вставил («Это не техника дошла, это Бокс.нет сам иконки вставил»)

ЗЫ: чуть не забыл — http://footballfake.blogi.ru/— ржал весь вечер…оч. прикольный стиль…надо будет тоже попробовать =))) автору респект…Гусев реально мудак, правильно его Широков обосрал…реально задолбал нытьем своим =))))

Лучший детский санаторий и организация детского отдыха; куда поехать летом

Паттерн Абстрактная фабрика (также извес…

Паттерн Абстрактная фабрика (также известен как Kit(инструментарий)) — предоставляет интерфейс для создания семейств, связанных между собой, или независимых объектов, конкретные классы которых неизвестны. Паттерн относится к порождающим, так как связан с процессом создания объектов.

Рассмотрим UML диаграмму шаблона:

Рассмотрим диаграмму на примере проектирования программы «Мир животных», в которой мы хотим «упорядочить» всех животных живущих в Европе и Африке:

AbstractFactory (фабрика Континентов) — объявляет интерфейс для операций, создающих абстрактные объекты-продукты;

ConcreteFactory (фабрика для Африки, фабрика для Европы) — конкретная фабрика. Реализует операции, создающие конкретные объекты-продукты;

AbstractProduct (Хищник, Травоядный) — абстрактный продукт. Объявляет интерфейс для типа объекта-продукта;

Product (Лев, Волк, Бизон, Медведь) — конкретный продукт. Определяет объект-продукт, создаваемый соответствующей конкретной фабрикой. Реализует интерфейс Abstract Product;

Client (Мир животных(приложение)) — клиент. Пользуется исключительно интерфейсами, которые объявлены в классах AbstractFactory и AbstractProduct.

Таким образом в проектируемой программе, создавая(инстанцируя) конкретную фабрику (к примеру для Европы), мы можем создавать семейство объектов с похожим поведением (Волк — хищник, живущий в Восточной Европе или Заяц — травоядный с ценным мехом). При этом созданием объектов-продуктов занимается непосредственно сама фабрика, поэтому нам нужен только ее один экземпляр. Зацитирую бандитов:

Фабрики и их продукция — вот ключевые участники паттерна абстрактная фабрика. Этот паттерн может создавать семейства объектов, не инстанцируя классы явно. Применять его лучше всего, когда число и общий вид изготавливаемых объектов остаются постоянными, но между конкретными семействами продуктов имеются различия. Выбор того или иного семейства осуществляется путем инстанцирования конкретной фабрики, после чего она используется для создания всех объектов. Подставив вместо одной фабрики другую, мы можем заменить все семейство объектов целиком. В паттерне абстрактная фабрика акцент делается на создании семейств объектов, и это отличает его от других порождающих паттернов, создающих только один какой-то вид объектов.

Вот некоторые проблемы которые помогает решать этот паттерн:

— Задание имени класса привязывает вас к конкретной реализации, а не к конкретному интерфейсу. Это может осложнить изменение объекта в будущем. Чтобы уйти от такой проблемы, создавайте объекты косвенно.
— Уход от аппаратной и программной зависимости
— Если клиент «знает», как объект представлен, хранится или реализован, то при изменении объекта может оказаться необходимым изменить и клиента. Сокрытие этой информации от клиентов поможет уберечься от каскада изменений.
— Уход от сильной связанности

Подробней читайте у GoF, а я перехожу к различным реализациям паттерна Абстрактная фабрика на C#:

1. Abstract Factory — реализация того самого примера с животными(+реализация из русской википедии), собственно говоря я и ориентировался на этот материал.

2. Abstract factory pattern — en-версия из Wiki. Наглядный пример того, как можно заюзать паттерн для какой-либо функции в Win-программе (или кроссплатформенной как в примере). UML:

3. Creational Patterns: Writing Abstract Factory pattern with c# — немного кривая реализация, но реально показывающая как можно применить паттерн для возможности легко выбирать БД (переносимость). В качестве Абстрактных фабрик применяются интерфейсы.

4. Abstract Factory — интересная реализация, показывающая возможность создавать несколько «частей» Win-приложения.

Abstract_Factory_Pattern.rar (65 К) реализации (1-4)

5. Pattern : Abstract Factory Creational Pattern — прекрасная UML диаграмма и пример того, какие удобные возможности предоставляет фабрика для создания фигур различного цвета.

6. The Abstract Factory Pattern — еще один прекрасный пример с такой диаграммой:

7. Паттерн разработки Abstract Factory — самая богатая коллекция различных подходов (с точки зрения C#) реализаций паттерна. Также рассматриваются решения некоторых проблем, возникающих при использовании паттерна.

8. .NET Abstract Factory — 5 примеров реализаций с кодом и UML… круче только несколько логотипов МТС.