SlideServe
Menu
Préférences
© SlideServe · v2026

Understanding the State and Composite Design Patterns in Software Development

keilah avatar
17 diapositives · 319 Views · Oct 14, 2014

The State and Composite design patterns are key concepts in software architecture, enhancing flexibility and organization. The State pattern allows an object to alter its behavior based on its internal state, enabling different responses tailored to its current conditions. For example, a Room may have states like Alright, SomeFaults, and ManyFaults, influencing its maintenance operations. The Composite pattern, on the other hand, facilitates complex tree structures, treating individual objects and compositions uniformly, simplifying operations on hierarchical structures. Together, they promote robust and scalable software design.

Understanding the State and Composite Design Patterns in Software Development - slide 1
01 / 17Understanding the State and Composite Design Patterns in Software Development
1 / 17

Télécharger la présentation

Understanding the State and Composite Design Patterns in Software Development
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation
  1. State Pattern • Intent • Alter behaviour of an object when its internal state changes • Object appears to change its class • Alternate names Objects for states

  2. State – Motivation • An object may be in one of many states. It responds differently depending upon its current state • Example • A Room can be in one of the states • Alright, SomeFaults, ManyFaults • A request to paint the room is made • Alright state – clean and paint room • SomeFaults– repair yourself and paint room • ManyFaults– hire contractor and paint room

  3. + ALRIGHT + SOME_FAULTS + MANY_FAULTS paint + furnish + paint + furnish + paint + furnish + State – Example Structure state + ROOM * ROOM_STATE paint * furnish * paint furnish

  4. * STATE operation * + A_STATE operation + State – Abstract Structure state + CONTEXT operation state.operation

  5. State – Participants • Context Defines client interface • Deferred State Defines interface for common behaviour for different states • Effective State Implements behaviour of that state in context

  6. State – Collaborations • Context delegates state specific behaviour to a concrete state object • Context may pass itself as an argument so that state can access context features • Context is the primary interface with clients • Clients configure context with state objects • Clients do not deal directly with state objects • Context or concrete state can decide which state follows another state

  7. State – Applicability • Object has different behaviour depending on state • Operations have multi-part conditional statement dependent upon state • State is represented by an enumerated constant • Several operations have same conditional structure • Pattern puts each branch of the conditional into a separate class • Object’s state becomes an object that can vary independently of other objects

  8. State – Related Patterns • State objects are often Singletons • Frequently, state classes do not contain any attributes • As a result, state objects of the same type are all the same • To avoid having many different objects that are exactly the same, one can make such classes singletons

  9. Composite Pattern • Intent • Compose objects into tree structures representing part-whole hierarchies • Clients deal uniformly with individual objects and hierarchies of objects

  10. Composite – Motivation • Applications that have recursive groupings of primitives and groups • Drawing programs lines, text, figures and groups • Eiffel static structure classes and clusters • Operations on groups are different than primitives but users treat them in the same way

  11. DIAGRAM DIAGRAM DIAGRAM DIAGRAM TEXT LINE OVAL OVAL TEXT TEXT Composite –  Drawing Example

  12. CLIENT COMPOSITE[T] * GRAPHIC * add * remove * iterate * draw * DIAGRAM + draw + add + remove + iterate + Composite – Example Architecture T TEXT + OVAL + LINE + draw + draw + draw +

  13. COMPONENT * CLIENT op_1 * op_2 * COMPOSITE[T] * add * remove * iterate * Composite – Abstract Architecture T LEAF + COMPOSITE_COMPONENT + op_1 + op_2 + op_1 + op_2 + add + remove + iterate +

  14. Composite – Applicability • Represent part-whole hierarchies of objects • Clients can ignore difference between individual objects and compositions • Clients deal with all objects in a composition in the same way

  15. Composite – Participants • Component Defines properties of an entity • Leaf Defines properties of a primitive entity • Composite Declares properties of a collection of entities • Composite Component Combines properties of a collection of entities and properties of a primitive entity • Client Uses component and composite properties

  16. Composite – Consequences • Whenever client expects a primitive it can accept a composite • Client is simplified by removing tag-case statements to identify parts of the composition • Easy to add new components by subclassing, client does not change • If compositions are to have restricted sets of components have to rely on run-time checking

  17. Composite – Related Patterns • Decorator is a degenerate Composite (only one component) • Visitor localizes operations that would be distributed across composite and leaf classes