🗊Презентация Патерни проектування

Патерни проектування 2005-2012

Що таке патерн (pattern)? Alexander C., Ishikawa S., Silverstein M. A Pattern Language: Towns/ Buildings/ Construction, NY, 1977. Alexander C., Ishikawa S., Silverstein M. The Timeless Way of Buildings, NY, 1979.

GoF (Gang of Four). Gamma E., Johnson R., Helm R., Vlissides J. Design Patterns. Elements of Reusable Object-Oriented Software. — Addison-Wesley, 1995. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб: Питер, 2001. — 368 с.

http://www.dofactory.com

http://sourcemaking.com/design_patterns

http://www.citforum.ru/SE/project/pattern/ (1/2)

http://www.citforum.ru/SE/project/pattern/ (2/2)

GRASP (General Responsibility Assignment Software Patterns)

Анти-патерни

Структура патернів GoF У загальному випадку опис патерну складається з чотирьох основних розділів: 1. Ім'я. Пославшись на нього, можна одразу описати як проблему проектування, так і її вирішення (словник патернів). Отже, проектування ПС можна проводити більш високому рівні абстракції. Патерн — це одне з ключових понять архітектури ПС. Знаходження виразних імен було однією з найскладніших задач при складанні каталогу GoF (Gang of Four). 2. Задача. Опис того, коли варто застосовувати патерн. Необхідно сформулювати задачу та її контекст. Тут може описуватися конкретна проблема проектування, може включатися перелік умов, при виконанні яких має сенс застосовувати даний патерн. (Важливо знати, де і при яких умовах можна скористатись патерном.)

Структура патернів 3. Розв'язок . Абстрактний опис задачі проектування і того, як вона може бути розв'язана за допомогою деякого узагальненого сполучення класів чи об'єктів. 4. Результати. Описуються наслідки застосування патерну, різного роду компроміси, аналізується вибір мови реалізації. Хоча при опису проектних рішень про наслідки часто не згадують, знати про них необхідно, щоб можна було оцінити переваги і недоліки даного патерну у порівнянні з іншими. Оскільки повторне використання є важливим фактором для ПС, то до результатів варто відносити вплив на гнучкість, масштабування, портабельність розроблюваної системи.

До класифікації патернів Породжуючі патерни – пов'язані з процесом створення об'єктів. Структурні патерни – ґрунтуються на композиціях (структурних об'єднаннях) об'єктів чи класів. (Теза: замість успадкування – композиції). Патерни поведінки – характеризуються взаємодією об'єктів між собою (такі патерни можна розглядати як кооперації UML).

Простір патернів проектування Cтруктурні патерни рівня об'єкта компонують об'єкти для одержання нової функціональності. Додаткова гнучкість пов'язана з можливістю задавати композицію об'єктів під час виконання програми, що неможливо для статичної композиції класів.

Singleton (data & object factory™, dofactory.com) Гарантує, що є тільки один екземпляр класу, і надає глобальну точку доступу до такого екземпляра.

Singleton (data & object factory™, dofactory.com)

Adapter http://sourcemaking.com/design_patterns

Adapter Дозволяє перейти від одного інтерфейсу (у класі чи в об'єкті) до іншого з метою забезпечити спільну роботу (класів чи об'єктів), яка була б неможлива без даного патерна через несумісність інтерфейсів.

Adapter

Adapter (GoF)

Borland Developer Studio 2006. Adapter

Borland Developer Studio 2006. Adapter

Borland Developer Studio 2006

Adapter (data & object factory™, dofactory.com)

Adapter (data & object factory™, dofactory.com) // "Adaptee" class Adaptee { // Methods public void SpecificRequest() { Console.WriteLine("Called SpecificRequest()" ); } } /// Client test public class Client { public static void Main(string[] args) { // Create adapter and place a request Target t = new Adapter(); t.Request(); } }

Adapter

Proxy

Proxy (data & object factory™, dofactory.com) Виступає сурогатом (заступником) іншого об'єкта, “контролюючи” доступ до нього.

Proxy (data & object factory™, dofactory.com) // "Proxy" class Proxy : Subject { RealSubject realSubject; public override void Request() { // Use 'lazy initialization' if (realSubject == null) { realSubject = new RealSubject(); } realSubject.Request(); } }

Decorator Декоратор – патерн, що структурує об'єкти. Динамічно додаються об'єкту нові обов'язки. Є гнучкою альтернативою породженню підкласів з метою розширення функціональності.

Decorator

Decorator (data & object factory™, dofactory.com)

Decorator. Приклад (1/2) (data & object factory™, dofactory.com) public class Client { public static void Main ( string[] args ) { ConcreteComponent c = new ConcreteComponent(); ConcreteDecoratorA d1 = new ConcreteDecoratorA(); ConcreteDecoratorB d2 = new ConcreteDecoratorB(); // Link decorators d1.SetComponent( c ); d2.SetComponent( d1 ); d2.Operation(); } }

Decorator. Приклад (2/2)

Spring-проект dekor

Composite (композитор, компоновник) Групує об'єкти в деревоподібні структури для представлення ієрархій типу “частина-ціле”. Дозволяє уніфікувати дії як з листками, так і з будь-якими групами піддерев.

Composite (data & object factory™, dofactory.com)

Composite (data & object factory™, dofactory.com) class Leaf : Component {public Leaf( string name ) : base( name ) {} // Constructor public override void Add( Component c ) { Console.WriteLine("Cannot add to a leaf"); } public override void Remove( Component c ) { Console.WriteLine("Cannot remove from a leaf"); } public override void Display( int depth ) { Console.WriteLine( new String( '-', depth ) + name ); } } public class Client { public static void Main( string[] args ) { // Create a tree structure Composite root = new Composite( "root" ); root.Add( new Leaf( "Leaf A" )); root.Add( new Leaf( "Leaf B" )); Composite comp = new Composite( "Composite X" ); comp.Add( new Leaf( "Leaf XA" ) ); comp.Add( new Leaf( "Leaf XB" ) ); root.Add( comp ); root.Add( new Leaf( "Leaf C" )); // Recursively display nodes root.Display( 1 ); } }

Strategy (dofactory.com)

Strategy (dofactory.com) class ConcreteStrategyB : Strategy { public override void AlgorithmInterface() { Console.WriteLine( "CalledConcreteStrategyB.”+ ”AlgorithmInterface()"); } } class Context { private Strategy _strategy; // Constructor public Context(Strategy strategy) { this._strategy = strategy; } public void ContextInterface() { _strategy.AlgorithmInterface(); } }

Bridge

Bridge

Bridge

Bridge (GoF)

Bridge (data & object factory™, dofactory.com)

Bridge. “Починати з тих шаблонів, що створюють контекст для інших” (К.Александер).

Façade (data & object factory™, dofactory.com)

Observer (Спостерігач) Визначає між об'єктами відношення типу один (видавець) - до - багатьох (передплатників), так що при зміні стану одного об'єкта (видавця) всі підлеглі (передплатники) одержують повідомлення й автоматично оновлюють дані. Відомий також під іменами Dependents (підлеглі), Publish-Subscribe (видавець- передплатник).

Observer

Observer

Observer

Observer (data & object factory™, dofactory.com)

Observer (data & object factory™, dofactory.com) /// Client test public class Client { public static void Main( string[] args ) { // Configure Observer // structure ConcreteSubject s = new ConcreteSubject(); s.Attach(new ConcreteObserver( s, "X" ) ); s.Attach( new ConcreteObserver( s, "Y" ) ); s.Attach( new ConcreteObserver( s, "Z" ) ); // Change subject, notify // observers s.SubjectState = "ABC"; s.Notify(); } }

Додаток

Borland Developer Studio 2006

Borland Developer Studio 2006

Borland Developer Studio 2006

Borland Developer Studio 2006