Design Patterns and Components

1. Design Patterns and Components Prepared by : Mehmet Bilsay KARADENİZ

2. Design Patterns • Reusable solutions to recurring design problems in OO systems. • It describes the problem, the solution, when to apply the solution, and its consequences. • It also gives implementation hints and examples. • The solution is a general arrangement of objects and classes that solve the problem.

3. Others • Anti-Patterns: Things you souldn’t do. • AbstractionInversion(From less to more complex) • Analysis Paralysis (Too much analyse) • ...

4. DesignPatterns: CreationalPatterns StructuralPatterns BehavioralPatterns Desing Patterns

5. Patterns that parameterize the behavior of a system based on the classes of objects it creates. • AbstractFactoryPattern • BuilderPattern • FactoryMethodPattern • PrototypePattern • SingletonPattern • MonostatePattern CreationalPatterns

6. BeanPattern • EngineCollectionClass • EnvelopeLetter • ExternalizeTheStack • ProtocolStack • TombStone • WeakReferencePattern • AdapterPattern • BridgePattern • CompositePattern • DecoratorPattern • FacadePattern • FlyweightPattern • IteratorPattern • ProxyPattern • RetrofitInterfacePattern StructuralPatterns Patterns that use various language mechanisms for structuring code and assembling objects .

7. Describe how a group of objects collaborate to perform some task that no single object can perform alone. • MementoPattern • ObserverPattern • StatePattern • StrategyPattern • TemplateMethodPattern • VisitorPattern • BindingProperties • ChainOfResponsibilityPattern • CommandPattern • InterpreterPattern • IteratorPattern • MediatorPattern Behavioral Patterns

8. Singleton • If a system only needs one instance of a class, and that instance needs to be accessible in many different parts of a system, you control both instantiation and access by making that class a singleton. • Impementation: Static GetInstance Private Constructor • Monostate : All functions are static

9. Singleton

10. A class that exists to create instances of another class. • Implementation: • Implement a class for creating instances of classes. • GetInstance(TYPE_ID) AbstractFactory

11. AbstractFactory

12. Adapter • Lets classes with incompatible interfaces work together. • Convert the interface of some class b into an interface a that some client class c understands. • Implementation: Create a class that has the desired interface from some other class.

13. Adapter

14. Facade • Defines a higher-level interface that makes the subsystem easier to use. • Provide a unified interface to a set of interfaces in a subsystem. • Hides complexity. • Implementation : Create a class that has the desired simple interface from more complicated classes that has more detailed interfaces.

15. Facade

16. Other Practices • Implement according to interfaces. • Don’t use inheritance. It breaks abstraction. • Use delegation instead of inheritance. • Generics are hard to understand use with caution. • Applications are hard to design, toolkits (class libraries) are harder, and frameworks are the hardest to design.

17. Design Patterns Criticism • Don’t let enoug code reuse. • In practise it is not always efficient. • Most of them are missing language features (16 of 23). • Do not solve a problems, gives tools.

18. Component Orientation • Uses most core practises of design patterns. • Adresses most of the drawbacks. • ClassFactory, Adapter, ... etc can be widely used in component oeriented software design. • Component Design Patterns. Not meature enough.

19. Component Design Patterns • Distribution Patterns • DistributionOfComponents • LayeredComponentFramework • BypassableAbstraction • LocationAbstraction • ReplicatedObject • FacadeAtTheDistributionBoundary • ChokePoint • Connection Patterns • InterfaceDiscovery • ConnectionSingleton • ConnectionFlyweight • ConnectionObserver • Interaction Patterns • AbstractInteractions • ThirdPartyBinding • ComponentGlue • ComponentBus • ConsumerProducer • Behavior Patterns • ContainerIndependence • EnvironmentalAcquisition • ContainerManagedBehavior • ComponentManagedBehavior • DistributedCommand • InterruptibleCommand • TransactionalCommand • CommandConcurrency • Deployment Patterns • IndividualPackaging • GroupPackaging • PrebuiltFunctionality • AutomatedAssembly

20. Component Orientation Criticism • Dependency to other firms.(interface and strategy) • Development of components are harder. • Non-Standart (and possibly incompatible) component protocols. (COM,XPCOM,CORBA,...) • High learning delta.(coupled with big projects)

21. Component Orientation and Patterns • High learning delta and dependecy to other firms and component technologies can be reduced with adapter and bridge. • Design what you need or design with what you have ? • Which direction should we take ?

22. Thank you Questions ? Referances: http://www.c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley. ISBN 0-201-63361-2. http://www.dofactory.com/Patterns/Patterns.aspx Prepared by: Mehmet Bilsay KARADENİZ