курсовые,контрольные,дипломы,рефераты
Шаблоны проектирования
Abstract factory (Абстрактная фабрика)
Abstract factory (Абстрактная фабрика) — шаблон проектирования, позволяющий изменять поведение системы, варьируя создаваемые объекты, при этом сохраняя интерфейсы. Он позволяет создавать целые группы взаимосвязанных объектов, которые, будучи созданными одной фабрикой, реализуют общее поведение. Шаблон реализуется созданием абстрактного класса Factory, который представляет собой интерфейс для создания компонентов системы (например, для оконного интерфейса, он может создавать окна и кнопки). Затем пишутся наследующиеся от него классы, реализующие этот интерфейс.
Цель
Предоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов, не специфицируя их конкретных классов
Плюсы
изолирует конкретные классы;
упрощает замену семейств продуктов;
гарантирует сочетаемость продуктов.
Минусы
сложно добавить поддержку нового вида продуктов.
Применимость
Система не должна зависеть от того, как создаются, компонуются и представляются входящие в нее объекты; Входящие в семейство взаимосвязанные объекты должны использоваться вместе и вам необходимо обеспечить выполнение этого ограничения; Система должна конфигурироваться одним из семейств составляющих ее объектов; требуется предоставить библиотеку объектов, раскрывая только их интерфейсы, но не реализацию.
Пример C++
#include <iostream>
// AbstractProductA
class ICar
{
public:
virtual void info() = 0;
};
// ConcreteProductA1
class Ford : public ICar
{
public:
virtual void info()
{
std::cout << "Ford" << std::endl;
}
};
//ConcreteProductA2
class Toyota : public ICar
{
public:
virtual void info()
{
std::cout << "Toyota" << std::endl;
}
};
// AbstractProductB
class IEngine
{
public:
virtual void getPower() = 0;
};
// ConcreteProductB1
class FordEngine : public IEngine
{
public:
virtual void getPower()
{
std::cout << "Ford Engine 4.4" << std::endl;
}
};
//ConcreteProductB2
class ToyotaEngine : public IEngine
{
public:
virtual void getPower()
{
std::cout << "Toyota Engine 3.2" << std::endl;
}
};
// AbstractFactory
class CarFactory
{
public:
ICar* getNewCar()
{
return createCar();
}
IEngine* getNewEngine()
{
return createEngine();
}
protected:
virtual ICar*createCar()= 0;
virtual IEngine*createEngine()= 0;
};
// ConcreteFactory1
class FordFactory : public CarFactory
{
protected:
// from CarFactory
virtual ICar* createCar()
{
return new Ford();
}
virtual IEngine* createEngine()
{
return new FordEngine();
}
};
// ConcreteFactory2
class ToyotaFactory : public CarFactory
{
protected:
// from CarFactory
virtual ICar* createCar()
{
return new Toyota();
}
virtual IEngine* createEngine()
{
return new ToyotaEngine();
}
};
int main()
{
CarFactory* curFactory= NULL;
ICar*myCar= NULL;
IEngine*myEngine= NULL;
ToyotaFactorytoyotaFactory;
FordFactoryfordFactory;
curFactory = &toyotaFactory;
myCar = curFactory->getNewCar();
myCar->info();
myEngine = curFactory->getNewEngine();
myEngine->getPower();
delete myCar;
delete myEngine;
curFactory = &fordFactory;
myCar = curFactory->getNewCar();
myCar->info();
myEngine = curFactory->getNewEngine();
myEngine->getPower();
delete myCar;
delete myEngine;
return 0;
}
Builder (Строитель) — шаблон проектирования, порождающий объекты.
Цель
Отделяет конструирование сложного объекта от его представления, так что в результате одного и того же процесса конструирования могут получаться разные представления.
Плюсы
позволяет изменять внутреннее представление продукта;
изолирует код, реализующий конструирование и представление;
дает более тонкий контроль над процессом конструирования.
Применение
алгоритм создания сложного объекта не должен зависеть от того, из каких частей состоит объект и как они стыкуются между собой;
процесс конструирования должен обеспечивать различные представления конструируемого объекта.
Пример на C++
#include <iostream>
#include <memory>
#include <string>
// Product
class Pizza
{
private:
std::string dough;
std::string sauce;
std::string topping;
public:
Pizza() { }
~Pizza() { }
void SetDough(const std::string& d) { dough = d; };
void SetSauce(const std::string& s) { sauce = s; };
void SetTopping(const std::string& t) { topping = t; }
void ShowPizza()
{
std::cout << " Yummy !!!" << std::endl
<< "Pizza with Dough as " << dough
<< ", Sauce as " << sauce
<< " and Topping as " << topping
<< " !!! " << std::endl;
}
};
// Abstract Builder
class PizzaBuilder
{
protected:
std::auto_ptr<Pizza> pizza;
public:
PizzaBuilder() {}
virtual ~PizzaBuilder() {}
std::auto_ptr<Pizza> GetPizza() { return pizza; }
void createNewPizzaProduct() { pizza.reset (new Pizza); }
virtual void buildDough()=0;
virtual void buildSauce()=0;
virtual void buildTopping()=0;
};
// ConcreteBuilder
class HawaiianPizzaBuilder : public PizzaBuilder
{
public:
HawaiianPizzaBuilder() : PizzaBuilder() {}
~HawaiianPizzaBuilder(){}
void buildDough() { pizza->SetDough("cross"); }
void buildSauce() { pizza->SetSauce("mild"); }
void buildTopping() { pizza->SetTopping("ham and pineapple"); }
};
// ConcreteBuilder
class SpicyPizzaBuilder : public PizzaBuilder
{
public:
SpicyPizzaBuilder() : PizzaBuilder() {}
~SpicyPizzaBuilder() {}
void buildDough() { pizza->SetDough("pan baked"); }
void buildSauce() { pizza->SetSauce("hot"); }
void buildTopping() { pizza->SetTopping("pepperoni and salami"); }
};
// Director
class Waiter
{
private:
PizzaBuilder* pizzaBuilder;
public:
Waiter() : pizzaBuilder(NULL) {}
~Waiter() { }
void SetPizzaBuilder(PizzaBuilder* b) { pizzaBuilder = b; }
std::auto_ptr<Pizza> GetPizza() { return pizzaBuilder->GetPizza(); }
void ConstructPizza()
{
pizzaBuilder->createNewPizzaProduct();
pizzaBuilder->buildDough();
pizzaBuilder->buildSauce();
pizzaBuilder->buildTopping();
}
};
// Клиент заказывает две пиццы.
int main()
{
Waiter waiter;
HawaiianPizzaBuilder hawaiianPizzaBuilder;
waiter.SetPizzaBuilder (&hawaiianPizzaBuilder);
waiter.ConstructPizza();
std::auto_ptr<Pizza> pizza = waiter.GetPizza();
pizza->ShowPizza();
SpicyPizzaBuilder spicyPizzaBuilder;
waiter.SetPizzaBuilder(&spicyPizzaBuilder);
waiter.ConstructPizza();
pizza = waiter.GetPizza();
pizza->ShowPizza();
return EXIT_SUCCESS;
}
Factory Method (Фабричный метод) — шаблон проектирования, реализующий идею "виртуального конструктора", то есть создания объектов без явного указания их типа. Относится к порождающим шаблонам проектирования.
Цель
Определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанциировать. Фабричный метод позволяет классу делегировать создание подклассам.
Используется, когда:
классу заранее неизвестно, объекты каких подклассов ему нужно создавать.
класс спроектирован так, чтобы объекты, которые он создаёт, специфицировались подклассами.
класс делегирует свои обязанности одному из нескольких вспомогательных подклассов, и планируется локализовать знание о том, какой класс принимает эти обязанности на себя.
Плюсы
позволяет сделать код создания объектов более универсальным, не привязываясь к конкретным классам (ConcreteProduct), а оперируя лишь общим интерфейсом (Product);
позволяет установить связь между параллельными иерархиями классов.
Минусы
необходимость создавать наследника Creator для каждого нового типа продукта (ConcreteProduct).
· Product - продукт
o определяет интерфейс объектов, создаваемых абстрактным методом;
· ConcreteProduct - конкретный продукт
o реализует интерфейс Product;
· Creator - создатель
o объявляет фабричный метод, который возвращает объект типа Product. Может также содержать реализацию этого метода "по умолчанию";
o может вызывать фабричный метод для создания объекта типа Product;
· ConcreteCreator - конкретный создатель
o переопределяет фабричный метод таким образом, чтобы он создавал и возвращал объект класса ConcreteProduct.
Пример на C++
#include<iostream>
#include<string>
using namespace std;
// "Product"
class Product{
public:
virtual string getName() = 0;
};
// "ConcreteProductA"
class ConcreteProductA : public Product{
public:
string getName(){
return "ConcreteProductA";
}
};
// "ConcreteProductB"
class ConcreteProductB : public Product{
public:
string getName(){
return "ConcreteProductB";
}
};
class Creator{
public:
virtual Product* FactoryMethod() = 0;
};
// "ConcreteCreatorA"
class ConcreteCreatorA : public Creator{
public:
Product* FactoryMethod() {
return new ConcreteProductA();
}
};
// "ConcreteCreatorB"
class ConcreteCreatorB : public Creator{
public:
Product* FactoryMethod() {
return new ConcreteProductB();
}
};
int main(){
const int size = 2;
// An array of creators
Creator* creators[size];
creators[0] = new ConcreteCreatorA();
creators[1] = new ConcreteCreatorB();
// Iterate over creators and create products
for(int i=0;i<size;i++){
Product* product = creators[i]->FactoryMethod();
cout<<product->getName()<<endl;
delete product;
}
int a;
cin>>a;
for(int i=0;i<size;i++){
delete creators[i];
}
return 0;
}
Prototype (Прототип) — шаблон проектирования, порождающий объекты.
Назначение
Задаёт виды создаваемых объектов с помощью экземпляра-прототипа и создаёт новые объекты путём копирования этого прототипа.
Применимость
Используйте этот шаблон проектирования, когда система не должна зависеть от того, как в ней создаются, компонуются и представляются продукты:
инстанцируемые классы определяются во время выполнения, например с помощью динамической загрузки;
для того чтобы избежать построения иерархий классов или фабрик, параллельных иерархии классов продуктов;
экземпляры класса могут находиться в одном из нескольких различных состояний. Может оказаться удобнее установить соответствующее число прототипов и клонировать их, а не инстанцировать каждый раз класс вручную в подходящем состоянии.
Adapter (Адаптер)
Адаптер, Adapter — структурный шаблон проектирования, предназначенный для организации использования функций объекта, недоступного для модификации, через специально созданный интерфейс.
Назначение для организации использования функций объекта, недоступного для модификации, через специально созданный интерфейс (приводит интерфейс класса (или нескольких классов) к интерфейсу требуемого вида)
Применяется в случаях система поддерживает требуемые данные и поведение, но имеет неподходящий интерфейс. Чаще всего шаблон Адаптер применяется если необходимо создать класс, производный от вновь определяемого или уже существующего абстрактного класса.
Задача
Система поддерживает требуемые данные и поведение, но имеет неподходящий интерфейс. Чаще всего шаблон Адаптер применяется если необходимо создать класс, производный от вновь определяемого или уже существующего абстрактного класса.
Способ решения
Адаптер предусматривает создание класса-оболочки[1] с требуемым интерфейсом.
Реализация
Включение уже существующего класса в другой класс. Интерфейс включающего класса приводится в соответствие с новыми требованиями, а вызовы его методов преобразуются в вызовы методов включённого класса.
Участники
Класс Adapter приводит интерфейс класса Adaptee в соответствие с интерфейсом класса Target (наследником которого является Adapter). Это позволяет объекту Client использовать объект Adaptee так, словно он является экземпляром класса Target.
Следствия
Шаблон Адаптер позволяет включать уже существующие объекты в новые объектные структуры, независимо от различий в их интерфейсах.
Плюсы
инкапсуляция реализации внешних классов (компонентов, библиотек), система становится независимой от интерфейса внешних классов;
переход на использование других внешних классов не требует переделки самой системы, достаточно реализовать один класс Adapter.
Замечания и комментарии
Шаблон Адаптер позволяет в процессе проектирования не принимать во внимание возможные различия в интерфейсах уже существующих классов. Если есть класс, обладающий требуемыми методами и свойствами (по крайней мере, концептуально), то при необходимости всегда можно воспользоваться шаблоном Адаптер для приведения его интерфейса к нужному виду.
Близким Адаптеру является шаблон Фасад, не всегда можно отличить один от другого[2].
Применение шаблона
Типичным примером использования шаблона Адаптер можно назвать создание классов, приводящих к единому интерфейсу функции языка PHP обеспечивающие доступ к различным СУБД[3].
Bridge (Мост)
Bridge (Мост) — шаблон проектирования, используемый в проектировании программного обеспечения чтобы "разделять абстракцию и реализацию так, чтобы они могли изменяться независимо". Шаблон bridge (от англ. — мост) использует инкапсуляцию, агрегирование и может использовать наследование для того, чтобы разделить ответственность между классами.
Цель
При частом изменении класса, преимущества объектно-ориентированного подхода становятся очень полезными, позволяя делать изменения в программе, обладая минимальными сведениями о реализации программы. Шаблон bridge является полезным там, где не только сам класс часто меняется, но и то, что класс делает.
Описание
Когда абстракция и реализация разделены, они могут изменяться независимо. Рассмотрим такую абстракцию как фигура. Существует множество типов фигур, каждая со своими свойствами и методами. Однако есть что-то, что объединяет все фигуры. Например, каждая фигура должна уметь рисовать себя, масштабироваться ит.п. В то же время рисование графики может отличаться в зависимости от типа ОС, или графической библиотеки. Фигуры должны иметь возможность рисовать себя в различных графических средах, но реализовывать в каждой фигуре все способы рисования или модифицировать фигуру каждый раз при изменении способа рисования непрактично. В этом случае помогает шаблон bridge, позволяя создавать новые классы, которые будут реализовывать рисование в различных графических средах. При использовании такого подхода очень легко можно добавлять как новые фигуры, так и способы их рисования.
Composite pattern (Компоновщик)
Composite pattern (Компоновщик)— шаблон проектирования, объединяет объекты в древовидную структуру для представления иерархии от частного к целому. Компоновщик позволяет клиентам обращаться к отдельным объектам и к группам объектов одинаково.
Описание
Decorator (Декоратор)
Decorator (Декоратор) — структурный шаблон проектирования, предназначенный для динамического подключения дополнительного поведения к объекту. Шаблон Декоратор предоставляет гибкую альтернативу практике созданию подклассов с целью расширения функциональности.
Назначение
Для динамического подключения к объекту дополнительных обязательств
Задача
Объект, который предполагается использовать, выполняет основные функции. Однако может потребоваться добавить к нему некоторую дополнительную функциональность, которая будет выполняться до или после основной функциональности объекта.
Способ решения
Декоратор предусматривает расширение функциональности объекта без определения подклассов.
Участники
Класс ConcreteComponent — класс, в который с помощью шаблона Декоратор добавляется новая функциональность. В некоторых случаях базовая функциональность предоставляется классами, производными от класса ConcreteComponent. В подобных случаях класс ConcreteComponent является уже не конкретным, а абстрактным. Абстрактный класс Component определяет интерфейс для использования всех этих классов.
Следствия
Добавляемая функциональность реализуется в небольших объектах. Преимущество состоит в возможности динамически добавлять эту функциональность до или после основной функциональности объекта ConcreteComponent.
Реализация
Создается абстрактный класс, представляющий как исходный класс, так и новые, добавляемые в класс функции. В классах-декораторах новые функции вызываются в требуемой последовательности — до или после вызова последующего объекта.
Замечания и комментарии
Хотя объект-декоратор может добавлять свою функциональность до или после функциональности основного объекта, цепочка создаваемых объектов всегда должна заканчиваться объектом класса ConcreteComponent.
Плюсы
нет необходимости создавать подклассы для расширения функциональности объекта;
возможность динамически подключать новую функциональность до или после основной функциональности объекта ConcreteComponent.
Chain of responsibility (цепочка обязанностей)
Цепочка обязанностей — поведенческий шаблон проектирования, предназначенный для организации в системе уровней ответственности.
Назначение
для организации в системе уровней ответственности
Применение
Шаблон рекомендован для использования в условиях:
в разрабатываемой системе имеется группа объектов, которые могут обрабатывать сообщения определенного типа;
все соообщения должны быть обработаны хотя бы одним объектом системы;
сообщения в системе обрабатываются по схеме "обработай сам либо перешли другому", то есть одни сообщения обрабатываются на том уровне, где они получены, а другие пересылаются объектам иного уровня.
Command (Команда)
Command (Команда) — шаблон проектирования, используемый при объектно-ориентированном программировании, представляющий действие. Объект команды заключает в себе само действие и его параметры.
Назначение
для обработки команды в виде объекта
Описание
Обеспечивает обработку команды в виде объекта, что позволяет сохранять её, передавать в качестве параметра методам, а также возвращать её в виде результата, как и любой другой объект.
Например, библиотека печати может иметь класс PrintJob. Для его использования можно создать объект PrintJob, установить необходимые параметры, и вызвать метод, непосредственно отсылающий задание на печать.
Iterator (Итератор)
Iterator (Итератор) – Шаблон проектирования. Представляет собой объект, позволяющий последовательный доступ к элементам объекта-агрегата без использования описаний каждого из объектов, входящий в состав агрегации.
Observer (Наблюдатель)
Observer (Наблюдатель)— поведенческий шаблон проектирования. Также известен как "подчинённые" (Dependents), "издатель-подписчик" (Publisher-Subscriber).
Назначение
Определяет зависимость типа "один ко многим" между объектами таким образом, что при изменении состояния одного объекта все зависящие от него оповещаются об этом событии.
При реализации шаблона "наблюдатель" обычно используются следующие классы.
Observable — интерфейс, определяющий методы для добавления, удаления и оповещения наблюдателей.
Observer — интерфейс, с помощью которого наблюдаемый объект оповещает наблюдателей.
ConcreteObservable — конкретный класс, который реализует интерфейс Observable.
ConcreteObserver — конкретный класс, который реализует интерфейс Observer.
Область применения
Шаблон "наблюдатель" применяется в тех случаях, когда система обладает следующими свойствами:
существует, как минимум, один объект, рассылающий сообщения
имеется не менее одного получателя сообщений, причём их количество и состав могут изменяться во время работы приложения.
Данный шаблон часто применяют в ситуациях, в которых отправителя сообщений не интересует, что делают с предоставленной им информацией получатели.
State (Состояние)
State (Состояние) — шаблон проектирования. Используется в тех случаях, когда во время выполнения программы объект должен менять свое поведение в зависимости от своего состояния.
Паттерн состоит из 3 блоков:
Widget — класс, объекты которого должны менять свое поведение в зависимости от состояния.
IState — интерфейс, который должно реализовать каждое из конкретных состояний. Через этот интерфейс объект Widget взаимодействует с состоянием, делегируя ему вызовы методов. Интерфейс должен содержать средства для обратной связи с объектом, поведение которого нужно изменить. Для этого используется событие (паттерн Publisher — Subscriber). Это необходимо для того, чтобы в процессе выполнения программы заменять объект состояния при появлении событий. Возможны случаи, когда сам Widget периодически опрашивает объект состояние на наличие перехода.
StateA … StateZ — классы конкретных состояний. Должны содержать информацию о том, при каких условиях и в какие состояния может переходить объект из текущего состояния. Например, из StateA объект может переходить в состояние StateB и StateC, а из StateB — обратно в StateA и так далее. Объект одного из них должен содержать Widget при создании.
Шаблоны проектирования Abstract factory (Абстрактная фабрика) Abstract factory (Абстрактная фабрика) — шаблон проектирования, позволяющий изменять поведение системы, варьируя создаваемые объекты, при этом сохраняя интерфейсы.
Copyright (c) 2024 Stud-Baza.ru Рефераты, контрольные, курсовые, дипломные работы.