Please enable JavaScript.
Coggle requires JavaScript to display documents.
Design patterns (Visitor behavioral design pattern (Implementare (Visitor…
Design patterns
Visitor
behavioral design pattern
represents an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates
Problem solved:
-o structura contine obiecte de clase variate, asupra carora vrem sa aplicam op ce depind de clasele lor concrete
-operatiile pe care vrem sa le aplicam sunt diferite, fara legatura intre ele si ar trebui sa fie usor extensibile
-clasele ce definesc structura de obiecte se schimba rar, dar vrem sa definim operatii noi usor
Double dispatch: o actiune (precum Accept) depinde de tipul a 2 elemente (in cazul Accept de tipul vizitatorului si al obiectului vizitat)
Conclusions:
-adaugarea de op este simpla
-vizitatorul grupeaza op in mod logic
-adaugarea de noi clase e mai dificila
-vizitatorul poate acumula stare
Implementare
Visitor: visit(diverse)
Visitable: accept(visitor v)
ConcreteVisitable: accept(v) = v.visit(this)
Proxy
structural design pattern
provides a surrogate or placeholder for another object to control access to it
Problem solved:
-uneori vrem sa amanam crearea si initializarea unui obiect pana in momentul in care avem nevoie de el
tipuri de proxy:
-virtual proxy
-remote p
-protection
-smart reference
introduce un nivel logic in folosirea unui obiect, pentru:
-a ascunde locatia obiectului
-a verifica cine solicita accesul si a-l proteja
-a introduce logica suplim (copy-on-write)
https://www.tutorialspoint.com/design_pattern/proxy_pattern.htm
Command
behavioral design pattern
encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations
Problem solved:
-invoker invoca receiver sa realizeze o operatie, fara sa stie cum se va realiza
-vrem sa ad mai multe operatii, sa specificam ordinea sau momentul in care se realizeaza
-cautam un loc in care sa specif starea de dinainte de realizarea operatiei pt a o putea inversa
ex: java.lang.Runnable
Conclusions:
-decupleaza obj ce solicita o op de obj care stie sa o rezolve
-adaugarea de noi comenzi e usoara
Implementare
Command interface: execute()
ConcreteCommand: execute() = receiver.action(), state
Invoker:listOfCommands, takeCommand(c), executeCommands()
Receiver: action()
Strategy
behavioral design pattern
defines a family of algorithms, encapsulates each one and makes them interchangeable. Strategy lets the algo vary independently from clients who use it.
Problem solved:
-vrem sa alegem la runtime var de algo cea mai potrivita sau aceasta depinde de multe conditii
-vrem sa nu ingreunam clasa cu implementari de algoritmi
ex: java.util.Comparator#compare() executat de Collections.sort()
Conclusions:
-grupeaza algo asemanatori, partile comune evidentiate prin mostenire
-incapsuleaza instr decizionale, eliminandu-le astfel din client
-comunicare crescuta intre context si algo
-nr mai mare de obj
Implementare
Context: strategy, executeStrategy() = strategy.doOperation(blabla)
Strategy interface: doOperation(blabla)
ConcreteStrategy: doOperation(blabla)
Iterator
behavioral design pattern
provides a way to access the elements of an aggregate object (ex list) sequentially without exposing its underlying representation
Problem solved:
-de multe ori avem nevoie sa parcurgem elementele unor structuri de date agregate (liste arbori grafuri)
-parcurgerea se poate face in multe feluri (listele stanga-dreapta sau dreapta-stanga, cu filtru, poz pare etc), implementarea tuturor ar incarca structura de date agregata in mod inutil
Solution:
-crearea iteratorului ar trebui sa apartina structurii de date agregate, care ii cunoaste implementarea
-un iterator robust suporta adaugari si extrageri de elem pe parcursul traversarii
Conclusions:
-ofera posibilit de a varia modalitatea de traversare
-simplifica interfata structurii de date agregate
-pot exista mai multi iteratori concomitent asupra unei structuri de date agregate, deci mai multe traversari concomitente
Implementare
Aggregate interface: createIterator() = return new ConcreteIterator(this);
Iterator: hasNext(), next(), remove(), add(), set()
http://codereview.stackexchange.com/questions/112109/filtered-iterator
Observer
behavioral design pattern
defines dependency between objects so that when one object changes state, all its dependents are notified and updated automatically (aka publisher-subscriber)
Problem solved:
-mai multe obj depind de aceeasi info
-nu vrem sa le legam strans, vrem ca rel dintre ele sa poata fi dinamica
Implementare
Subject interface: attach(observer), detach(o), notify()
ConcreteSubject: getState() = return subjState, setState(), subjState
Observer interface: update()
ConcreteObserver: update() = obsState = subj.getState(), observerState
Conclusions:
-relatie abstracta intre obs si obiecte
-broadcast
Decorator
structural design pattern
allows to attach responsibilites to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality
Problem solved:
-vrem sa ad functionalitate doar unor anumite obiecte si nu clasei intregi
-vrem sa adaugam functionalitate si sa o putem revoca dinamic
-folosit cand mostenirea nu e practica
http://stackoverflow.com/questions/2707401/please-help-me-understand-the-decorator-pattern-with-a-real-world-example
Conclusions:
-flexibilitate sporita
-evita clase ft mari, dar duce la crearea de mai multe clase mici
-decoratorul si componenta sunt separare, spre deoseb de mostenirea clasica
Builder
creational design pattern
java.lang.StringBuilder
https://www.dotnetperls.com/stringbuilder-java
Composite
structural design pattern
Implementare
Employee: listOfEmployees, (ex) print() = print current then for(all subordinates) print subordinate
Factory
creational design pattern
Singleton
creational design pattern
Reflection
NU NE MAI TREBUIE
Injection
Exemple de chestii ce folosesc design patterns:
http://stackoverflow.com/questions/1673841/examples-of-gof-design-patterns-in-javas-core-libraries