Design
Patterns.Architectural
styles
Lecture 10. Yemberdiyeva Aknur, Senior Lecturer
• Software professionals may be familiar with the term “Design
Patterns,” but many have no idea of where they come from and what
they truly are. Consequently, some do not see the value and benefits
design patterns bring to the software development process, especially
in the areas of maintenance and code reuse.
What Are Design Patterns?
• Design patterns are commonly defined as time-tested
solutions to recurring design problems. The term refers
to both the description of a solution that you can read
and an instance of that solution as used to solve a
particular problem. (I like the analogy of comparing
design patterns to a class and an object instance of the
class. Each is a different way to represent a thing.)
• Design patterns are represented as relationships between
classes and objects with defined responsibilities that act in
concert to carry out the solution. To illustrate a design
pattern, consider the Adapter pattern, one of the original 23
patterns described in Design Patterns. Adapter provides a
solution to the scenario in which a client and server need to
interact with one another, but cannot because their
interfaces are incompatible. To implement an Adapter, you
create a custom class that honors the interface provided by
the server and defines the server operations in terms the
client expects. This is a much better solution than altering
the client to match the interface of the server.
• The design pattern community is growing both in membership
and coverage. The pattern literature describes new patterns that
solve emerging issues related to technical advancements. As a
software professional, you are the beneficiary of this body of
knowledge. To use these patterns, you will need to learn them and
become familiar with them so you will know which pattern to pull
from your toolbox when a design issue arises. Many patterns have
been documented over the years. They have been classified in
different ways by different authors. Take the time to learn
different ways to classify design patterns because you will gain
greater insight into them. As you learn more and more patterns, it
would be a good idea to develop your own classification system;
one reflecting the way you utilize them.
What is the Structure of a Design Pattern?
• Design pattern documentation is highly structured. The
patterns are documented from a template that identifies the
information needed to understand the software problem and
the solution in terms of the relationships between the classes
and objects necessary to implement the solution. There is no
uniform agreement within the design pattern community on
how to describe a pattern template. Different authors prefer
different styles for their pattern templates. Some authors
prefer to be more expressive and less structured, while others
prefer their pattern templates to be more precise and high
grain in structure. We will use the template first described by
the authors of Design Patterns to illustrate a template.
• This template captures the essential information
required to understand the essence of the problem and
the structure of the solution. Many pattern templates
have less structure than this but basically cover the
same content.
What Are the Benefits of Design Patterns?
• Design patterns have two major benefits. First, they provide
you with a way to solve issues related to software
development using a proven solution. The solution facilitates
the development of highly cohesive modules with minimal
coupling. They isolate the variability that may exist in the
system requirements, making the overall system easier to
understand and maintain. Second, design patterns make
communication between designers more efficient. Software
professionals can immediately picture the high-level design
in their heads when they refer to the name of the pattern
used to solve a particular issue when discussing system
design.
Creational design patterns
• These design patterns are all about class instantiation.
This pattern can be further divided into class-creation
patterns and object-creational patterns. While class-
creation patterns use inheritance effectively in the
instantiation process, object-creation patterns use
delegation effectively to get the job done.
• Abstract Factory
Creates an instance of several families of classes
• Builder
Separates object construction from its representation
• Factory Method
Creates an instance of several derived classes
• Object Pool
Avoid expensive acquisition and release of resources by
recycling objects that are no longer in use
• Prototype
A fully initialized instance to be copied or cloned
• Singleton
A class of which only a single instance can exist
Structural design patterns
• Adapter
Match interfaces of different classes
• Bridge
Separates an object’s interface from its implementation
• Composite
A tree structure of simple and composite objects
• Decorator
Add responsibilities to objects dynamically
• Facade
A single class that represents an entire subsystem
• Flyweight
A fine-grained instance used for efficient sharing
• Behavioral design patterns
• These design patterns are all about Class's
objects communication. Behavioral
patterns are those patterns that are most
specifically concerned with communication
between objects.
• Chain of responsibility
A way of passing a request between a chain of objects
• Command
Encapsulate a command request as an object
• Interpreter
A way to include language elements in a program
• Iterator
Sequentially access the elements of a collection
• Mediator
Defines simplified communication between classes
• Memento
Capture and restore an object's internal state
• Null Object
Designed to act as a default value of an object
• Observer
A way of notifying change to a number of classes
• State
Alter an object's behavior when its state changes
• Strategy
Encapsulates an algorithm inside a class
• Template method
Defer the exact steps of an algorithm to a subclass
• Visitor
Defines a new operation to a class without change
Шаблон «Стратегия»
Шаблон «Адаптер»
Шаблон «Фабричный
метод»
ARCHITECTURAL
STYLES
▸ Architectural style
specifies
▸ how to partition a
system
▸ how components identify and communicate
with each other
▸ how information is communicated
A R C H I T E. C. T. U R
A. L STYLES
▸ Can also be characterized by one or more architectural
decisions
▸ e.g., elements in component A can send messages to
elements in component B but not vice versa (i.e.,
layers)
▸ Making this decision(s) immediately has one
or more consequences on architectural
requirements
▸ Often binary
Some common
architectural
styles
▸ Big ball of mud
▸ Layered
▸ Model-centered
▸ Publish/subscribe
▸ Pipe and filter
▸ REST
BIG BALL OF
MUD
▸ Forces
▸ Insufficient time to build the "right" way, with
consideration of how design decisions impact
maintainability
▸ Constraints: none
▸ Anything can go anywhere.
▸ Anything can be written in any way.
▸ Consequences
▸ Leads to system that is disorganized.
▸ Makes it hard to find where to make change,
LAYERED
ARCHITECT
URE
▸ Elements: layers
▸ Constraints: can only use lower layers
▸ Strictly layered: can only use adjacent lower layer
▸ Consequences
▸ Supports maintability by making it easier to find
functionality
▸ Supports portability and reusability by enabling
MODEL-
CENTER
ED
▸ Elements: model, view (optional), controller (optional), view-controller
(optional)
▸ Constraints
▸ Components interact with a central model rather than each other
▸ Changes originates outside of model, propagate to model, trigger
notifications to elements depending on model
▸ Synonyms: repository, shared-data, data-centered
▸ Consequences
▸ Maintainable: can write data processing in terms of model rather than in
terms of UI abstractions
EXAMPLE:
ANGULAR 1.0 --
MVVM
▸ Model: domain-specific data,
doesn't matter how much it's
interact with
▸ View
▸ Visual representation of current
state of model
▸ View does not communicate with
model directly Models are much
more dumb: no formatting, etc
PUBLISH/
SUBSCRI
BE
▸ Elements: component, event bus
▸ Components broadcast events to listeners on event bus
▸ Constraints
▸ Components do not know why an event is published
▸ Subscribing components do not know who published event,
depending on event type rather than specific publisher
▸ Synonyms: event-based, pub/sub
▸ Consequences
▸ Maintainability: can make changes to components without impacting
REST (REPRESENTATIONAL
STATE TRANSFER)
▸ Elements: HTTP server, request / response connector
▸ Constraints:
▸ Stateless: each client request contains all information necessary to service request
▸ Cacheable: clients and intermediaries may cache responses.
▸ Layered: client cannot determine if it is connected to end server or intermediary along
the way
▸ Uniform interface for resources: a single uniform interface (URIs) simplifies and
decouples architecture
▸ Consequences
▸ Scalability and reliability: enables servers to be added and removed at will at runtime
PIPE
AND
FILTER
▸ Elements: pipes, filters, read ports, write ports
▸ Constraints
▸ Filters may only interact through pipes
▸ Filters may not share any global state
▸ Filters may not make any assumptions about what happens upstream or downstream
▸ Filter should incrementally read input and generate output
▸ Consequences:
▸ Configurability, extensibility: can swap and compose networks of filters together, even at
runtime
FUNCTIONAL
REACTIVE
PROGRAMMING
▸ Elements: component, stream of events
▸ Constraints:
▸ Component only gets input from rest of system through stream of events;
cannot access or mutate data elsewhere
▸ When event arrives, changes state (resulting in new output) and may emit
event to other components
▸ Consequences
▸ Maintainability: much easier to make changes to individual element
DESIGN ACTIVITY: TODO
APPLICATION
▸ Form group of 3 or 4
▸ Your goal: design an architecture for a todo application by applying an architectural
style (see next slide)
▸ Todo application requirements
▸ User interactions with todos: add, delete, rename, complete, copy
▸ Display todos to user
▸ Persist todos
▸ Deliverables:
▸ component and connector model showing elements in your system
LIST OF ARCHITECTURAL
STYLES
▸ Only 2 groups may pick the same architectural style. Raise your hand
when you've selected a style to claim it.
▸ Architectural
styles
▸ Big ball of mud
▸ Layered
▸ Model-
centered
▸
Publish/subscri
be
SUMMARY
• ▸ Architectural style offer specific ways to
achieve architectural requirements
• ▸ Often offer ways to separate functionality into
separate elements and constraints on how these
elements can interact
• ▸ Violating constraints of an architectural style often
means that the consequences of the architectural
style will no longer be realized
