Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Integrative Programming Technology - Integrative Coding

Download as pdf or txt
Download as pdf or txt
You are on page 1of 45

Integrative Coding

Design Patterns and Interfaces


Terms to Ponder
Software Design Pattern a description or template for how to solve a problem
that can be used in many different situations.
Interaction is a kind of action that occurs as two or more objects have an effect
upon one another. The idea of a two-way effect is essential in the concept of
interaction, as opposed to a one-way causal effect
Best Practice a standard way of complying with legal or ethical requirements.
Object-oriented design Patterns that imply mutable state may be unsuited for
functional programming languages.
Software Design pattern
A software design pattern is a general,
reusable solution to a commonly occurring
problem within a given context in software
design. It is not a finished design that can be
transformed directly into source or machine
code. Rather, it is a description or template
for how to solve a problem that can be used
in many different situations. Design patterns
are formalized best practices that the
programmer can use to solve common
problems when designing an application or
system.
Software Design pattern
Object-oriented design patterns typically
show relationships and interactions between
classes or objects, without specifying the final
application classes or objects that are involved.
Patterns that simply mutable state may be
unsuited for functional programming languages,
some patterns can be rendered unnecessary in
languages that have built-in support for solving
the problem they are trying to solve, and
object-oriented patterns are not necessarily
suitable for non-object-oriented languages.
Software Design pattern
A best practice is a method or technique that has been generally
accepted as superior to any alternatives because it produces results
that are superior to those achieved by other means or because it has
become a standard way of doing things, e.g., a standard way of
complying with legal or ethical requirements.

• Design patterns can speed up the development process by providing tested,


proven development paradigms
• Effective software design requires considering issues that may not become
visible until later in the implementation.
• Freshly written code can often have hidden subtle issues that take time to be
detected, issues that sometimes can cause major problems down the road.
• Reusing design patterns helps to prevent such subtle issues, and it also
improves code readability for coders and architects who are familiar with the
patterns.
Classification and List
Design patterns had originally been categorized into 3 sub-classifications based
on kind of problem they solve.
❑Creational patterns provide the capability to create
objects based on a required criteria and in a controlled
way.
❑Structural patterns are about organizing different
classes and objects to form larger structures and
provide new functionality.
❑Behavioral patterns are about identifying common
communication patterns between objects and realize
these patterns.
Uses of Design Pattern
Design patterns can speed up the development
process by providing tested, proven development
paradigms. Effective software design requires
considering issues that may not become visible
until later in the implementation. Reusing design
patterns helps to prevent subtle issues that can
cause major problems and improves code
readability for coders and architects familiar with
the patterns.
Creational Pattern
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.
Creational Pattern
Abstract Intent
Factory Provide an interface for creating
families of related or dependent
objects without specifying their
concrete classes.
A hierarchy that encapsulates many
possible "platforms", and the
construction of a suite of "products".
The new operator considered harmful.
Creational Pattern
Abstract Discussion
Factory Provide a level of indirection that abstracts
the creation of families of related or
dependent objects without directly
specifying their concrete classes. The
"factory" object has the responsibility for
providing creation services for the entire
platform family. Clients never create
platform objects directly, they ask the
factory to do that for them.
Creational Pattern
Abstract Example
Factory The purpose of the Abstract Factory is
to provide an interface for creating
families of related objects, without
specifying concrete classes. This pattern
is found in the sheet metal stamping
equipment used in the manufacture of
Japanese automobiles.
Creational Pattern
Abstract Example
Factory The purpose of the
Abstract Factory is to
provide an interface
for creating families of
related objects,
without specifying
concrete classes. This
pattern is found in the
sheet metal stamping
equipment used in the
manufacture of
Japanese automobiles.

https://sourcemaking.com/files/v2/content/patterns/Abstract_Factory_example1.png
Creational Pattern
Builder Intent
Design Separate the construction of a complex
object from its representation so that
the same construction process can
create different representations.
Parse a complex representation, create
one of several targets..
Creational Pattern
Builder Problem
Design
An application needs to create the
elements of a complex aggregate.
The specification for the aggregate
exists on secondary storage and one
of many representations needs to be
built in primary storage.
Creational Pattern
Builder Discussion
Design Separate the algorithm for interpreting
(i.e. reading and parsing) a stored
persistence mechanism (e.g. RTF files)
from the algorithm for building and
representing one of many target
products (e.g. ASCII, TeX, text widget).
The focus/distinction is on creating
complex aggregates.
Creational Pattern
Builder Example
Design The Builder pattern separates the construction
of a complex object from its representation so
that the same construction process can create
different representations. This pattern is used
by fast food restaurants to construct children's
meals. Children's meals typically consist of a
main item, a side item, a drink, and a toy (e.g., a
hamburger, fries, Coke, and toy dinosaur).
Note that there can be variation in the content of the children's meal, but the
construction process is the same. Whether a customer orders a hamburger,
cheeseburger, or chicken, the process is the same. The employee at the counter
directs the crew to assemble a main item, side item, and toy. These items are
then placed in a bag.
Creational Pattern
Example
Builder The Builder pattern
separates the construction
Design of a complex object from its
representation so that the
same construction process
can create different
representations. This pattern
is used by fast food
restaurants to construct
children's meals. Children's
meals typically consist of a
main item, a side item, a
drink, and a toy (e.g., a
hamburger, fries, Coke, and
toy dinosaur).
Note that there can be variation in the content of
the children's meal, but the construction process is
the same. Whether a customer orders a hamburger,
cheeseburger, or chicken, the process is the same.
The employee at the counter directs the crew to
assemble a main item, side item, and toy. These
items are then placed in a bag.
Structural Design Pattern
These design patterns are all about
Class and Object composition.
Structural class-creation patterns use
inheritance to compose interfaces.
Structural object-patterns define
ways to compose objects to obtain
new functionality.
Structural Design Pattern
Adapter Intent
Design Convert the interface of a class into
another interface clients expect.
Adapter lets classes work together that
couldn't otherwise because of
incompatible interfaces.
Wrap an existing class with a new
interface. Impedance match an old
component to a new system.
Structural Design Pattern
Adapter Problem
Design An "off the shelf" component offers
compelling functionality that you
would like to reuse, but its "view of
the world" is not compatible with
the philosophy and architecture of
the system currently being
developed.
Structural Design Pattern
Discussion
Adapter Reuse has always been painful and elusive. One reason has been the
Design tribulation of designing something new, something old. There is
always something not quite right between the old and the new. It
may be physical dimensions or misalignment. It may be timing or
synchronization. It may be unfortunate assumptions or competing
standards.
Adapter is about creating an intermediary abstraction
that translates, or maps, the old component to the
new system. Clients call methods on the Adapter
object which redirects them into calls to the legacy
component. This strategy can be implemented either
with inheritance or with aggregation.
Structural Design Pattern
Adapter Example
The Adapter pattern allows otherwise incompatible
Design classes to work together by converting the interface
of one class into an interface expected by the
clients. Socket wrenches provide an example of the
Adapter. A socket attaches to a ratchet, provided
that the size of the drive is the same.
Typical drive sizes in the United States are 1/2" and
1/4". Obviously, a 1/2" drive ratchet will not fit into a
1/4" drive socket unless an adapter is used. A 1/2" to
1/4" adapter has a 1/2" female connection to fit on
the 1/2" drive ratchet, and a 1/4" male connection
to fit in the 1/4" drive socket.
Structural Design Pattern
Example
Adapter The Adapter pattern allows
otherwise incompatible classes to
Design work together by converting the
interface of one class into an
interface expected by the clients.
Socket wrenches provide an
example of the Adapter. A socket
attaches to a ratchet, provided
that the size of the drive is the
same.
Typical drive sizes in the United
States are 1/2" and 1/4".
Obviously, a 1/2" drive ratchet will
not fit into a 1/4" drive socket
unless an adapter is used. A 1/2"
to 1/4" adapter has a 1/2" female
connection to fit on the 1/2" drive
ratchet, and a 1/4" male
connection to fit in the 1/4" drive
socket.
Structural Design Pattern
Bridge Intent
Design Decouple an abstraction from its
implementation so that the two can
vary independently.
Publish interface in an inheritance
hierarchy, and bury implementation in
its own inheritance hierarchy.
Beyond encapsulation, to insulation.
Structural Design Pattern
Bridge Problem
Design "Hardening of the software arteries"
has occurred by using subclassing of an
abstract base class to provide
alternative implementations. This locks
in compile-time binding between
interface and implementation. The
abstraction and implementation cannot
be independently extended or
composed.
Structural Design Pattern
Bridge Discussion
Decompose the component's interface and
Design implementation into orthogonal class hierarchies. The
interface class contains a pointer to the abstract
implementation class. This pointer is initialized with an
instance of a concrete implementation class, but all
subsequent interaction from the interface class to the
implementation class is limited to the abstraction
maintained in the implementation base class.
The client interacts with the interface class, and it in turn
"delegates" all requests to the implementation class.
Structural Design Pattern
Bridge Discussion
The interface object is the "handle" known and
Design used by the client; while the implementation
object, or "body", is safely encapsulated to ensure
that it may continue to evolve, or be entirely
replaced (or shared at run-time.
Use the Bridge pattern when:
1. • you want run-time binding of the implementation,
2. • you have a proliferation of classes resulting from a
coupled interface and numerous implementations,
3. • you want to share an implementation among multiple
objects,
4. • you need to map orthogonal class hierarchies.
Structural Design Pattern
Bridge Discussion
Design Consequences include:
• decoupling the object's interface,
• improved extensibility (you can extend (i.e. subclass) the
abstraction and implementation hierarchies independently),
• hiding details from clients.
Structural Design Pattern
Example
Bridge The Bridge pattern
Design decouples
abstraction from its
an
implementation, so
that the two can vary
independently. A
household switch
controlling lights,
ceiling fans, etc. is an
example of the Bridge.
The purpose of the
switch is to turn a
device on or off. The
actual switch can be
implemented as a pull
chain, simple two
position switch, or a
variety of dimmer
switches
Behavioral Design Pattern
These design patterns are all about
Class's objects communication.
Behavioral patterns are those
patterns that are most specifically
concerned with communication
between objects.
Behavioral Design Pattern
Chain of Intent
Responsibility Avoid coupling the sender of a request to its
receiver by giving more than one object a
chance to handle the request. Chain the
receiving objects and pass the request along
the chain until an object handles it.
Launch-and-leave requests with a single
processing pipeline that contains many
possible handlers which is an object-
oriented linked list with recursive traversal.
Behavioral Design Pattern
Chain of Problem
Responsibility
There is a potentially variable number
of "handler" or "processing element" or
"node" objects, and a stream of
requests that must be handled. Need to
efficiently process the requests without
hard-wiring handler relationships and
precedence, or request-to-handler
mappings.
Behavioral Design Pattern
Chain of Discussion
Responsibility
Encapsulate the
processing elements
inside a "pipeline"
abstraction; and
have clients "launch
and leave" their
requests at the
entrance to the
pipeline.
Behavioral Design Pattern
Chain of Discussion
Responsibility The Chain of
Responsibility pattern
avoids coupling the
sender of a request to
the receiver by giving
more than one object a
chance to handle the
request. ATM use the
Chain of Responsibility in
money giving https://sourcemaking.com/files/sm/images/p
atterns/Chain_of_responsibility_example.png
mechanism.
Behavioral Design Pattern
Command Intent
Design
Encapsulate a request as an object,
thereby letting you parametrize clients
with different requests, queue or log
requests, and support undoable
operations.
Promote "invocation of a method on an
object" to full object status
Behavioral Design Pattern
Command Problem
Design
Need to issue requests to objects
without knowing anything about the
operation being requested or the
receiver of the request.
Behavioral Design Pattern
Command Discussion
Design
Command decouples the object that
invokes the operation from the one that
knows how to perform it. To achieve
this separation, the designer creates an
abstract base class that maps a receiver
(an object) with an action (a pointer to
a member function). The base class
contains an execute() method that
simply calls the action on the receiver.
Behavioral Design Pattern
Command Example
Design The Command pattern allows requests to be
encapsulated as objects, thereby allowing clients to
be parameterized with different requests. The
"check" at a diner is an example of a Command
pattern. The waiter or waitress takes an order or
command from a customer and encapsulates that
order by writing it on the check. The order is then
queued for a short order cook. Note that the pad of
"checks" used by each waiter is not dependent on
the menu, and therefore they can support
commands to cook many different items.
Behavioral Design Pattern
Command Example
The Command pattern allows
Design requests to be encapsulated
as objects, thereby allowing
clients to be parameterized
with different requests. The
"check" at a diner is an
example of a Command
pattern. The waiter or
waitress takes an order or
command from a customer
and encapsulates that order
by writing it on the check.
The order is then queued for
a short order cook. Note that
the pad of "checks" used by
each waiter is not dependent
on the menu, and therefore
they can support commands
to cook many different items.

https://sourcemaking.com/files/sm/images/patterns/Chain_of_responsibility_example.png
API (Application Programming Interface)
is a computing interface which defines interactions
between multiple software intermediaries. It defines
the kinds of calls or requests that can be made, how to
make them, the data formats that should be used, the
conventions to follow, etc. It can also provide extension
mechanisms so that users can extend existing
functionality in various ways and to varying degrees.
An API can be entirely custom, specific to a
component, or it can be designed based on an
industry-standard to ensure interoperability. Through
information hiding, APIs enable modular programming,
which allows users to use the interface independently
of the implementation.
API (Application Programming Interface)
In building applications, an API (application
programming interface) simplifies programming
by abstracting the underlying implementation
and only exposing objects or actions the
developer needs.
While a graphical interface for an email client
might provide a user with a button that performs
all the steps for fetching and highlighting new
emails, an API for file input/output might give the
developer a function that copies a file from one
location to another without requiring that the
developer understand the file system operations
occurring behind the scenes.
API (Application Programming Interface)
Software quality refers to two related but distinct notions:
Software functional quality reflects how well it
complies with or conforms to a given design,
based on functional requirements or
specifications. That attribute can also be described
as the fitness for purpose of a piece of software or
how it compares to competitors in the
marketplace as a worthwhile product. It is the
degree to which the correct software was
produced.
API (Application Programming Interface)
Software quality refers to two related but distinct notions:
• Software structural quality refers to how it
meets non-functional requirements that
support the delivery of the functional
requirements, such as robustness or
maintainability. It has a lot more to do with the
degree to which the software works as needed.

You might also like