Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
ISSN: 2221-0741
Vol. 6, No. 2, 12-20, 2016
Abstract In this paper, we present a general form of GoF Design Patterns as a process that transforms the BDPSP (the Basic
Design Pattern Structure of the Problem) to the BDPSS (the Basic Design Pattern Structure of the Solution), i.e. transforms the
unstable structure of the program to the stable structure. The stability of the BDPSP and BDPSS is explained by using Robert C.
Martins Stability metric. The BDPSP and BDPSS are described by three elements: Client, Abstract Server and Concrete Server.
The Client is an element of the pattern structure that uses the functionalities of the abstract server and concrete servers in order to
carry out its own functionality. The Abstract Server is an element of the pattern structure that provides the client with an abstract
functionalities that can be implemented with various specific functionalities. The Concrete Server is an element of the pattern
structure that provide the client with concrete functionalities that realise abstract functionalities of the abstract server. In this sense,
the Design Pattern is a process that relationship Client has Concrete Server, transform to relationships: a) Client has Abstract
Server and b) Concrete server is Abstract Server. We believe the BDPSS is the key mechanism or essence of the GoF design
patterns, which allow easy maintenance and upgrade of the program. We have showed that in 20 of 23 GoF design patterns the
BDPSS completely describes a pattern or a particular part of the pattern. We are using the general form of GoF design patterns in
the teaching process, as the first step in the overall understanding of the GoF design patterns, before a detailed explanation of the
specific characteristics of GoF design patterns. We think that this paper can greatly help the students and developers to quickly and
clearly understand the essence of GoF design patterns.
Keywords- Software design; Design patterns; Stability metric; Software stability; Software maintenance.
I.
INTRODUCTION
12
II.
T
Design
problem
Design
solution
13
In the book Design Patterns: Elements of Reusable ObjectOriented Software [DP], there are 23 GoF design patterns.
They are divided into three groups: creational patterns,
structural patterns and behavioral patterns. We have discovered
the structure that exist in 20 of these 23 patterns. This structure
eighter completely describes a pattern or some particular part
of the pattern. It is key mechanism or essence of GoF design
patterns. We called (Figure 4) this structure: The Basic
Design Pattern Structure of the Solution (BDPSS) . This
structure is presented on figure 2:
CL
AS
CS1
CS2
class Main
{ public static void main(String arg[])
{ CS1 cs1 = new CS1();
CS2 cs2 = new CS2();
...
CS2 csn = new CSn();
CSn
CL cl = new CL();
if (arg[0].equals(cs1))
cl.makeConnection(cs1);
if (arg[0].equals(cs2)
cl.makeConnection(cs2);
...
if (arg[0].equals(csn)
cl.makeConnection(csn);
cl.request();
}
}
we can say that, at compile time, the client (CL) knows that
will be connected with some object of classes (CS1, C22, ...,
CSn) that implement abstract server (AS), but in that moment,
it does not know the exact object (cs1or cs2,... or csn). The
Client makes connection, at run time, with concrete object.
That means, at run time will be resolved what concrete server
will realize the clients request. The relationship Client has AS
gives the program flexibility during its maintenance and
upgrade, because a clients request can be realized in many
different ways by using different concrete servers. This is
known as dynamic or late binding, that lets the mutual
subtitution of the objects, that have same interface, at run-time.
This substitutability is known as polymorphism [DP], which is
one of the key concepts in object-oriented design. The
advantage of BDPSS is reflected in the case, when we want to
add new concrete server CSn +1 to BDPSS,
14
request()
then we dont change the client, because the client is not related
to concrete servers than with the abstract server. Note that GoF
said [DP]: Each design pattern lets some aspect of system
structure vary independently of other aspects, thereby making a
system more robust to a particular kind of change. The
BDPSS lets that some aspect of system structure (Concrete
servers) vary independently of other aspects (Client). Also,
BDPSS is in compliance to one of the most important principle
Wholly more BDPSS:
More BDPSS are presented
wholly in the structure of the solution of the design patterns (4
design patterns).
Client
Abstract Server
Concrete Server
AbstractFactory
AbstractProductA
AbstractProductB
Builder
Product
Prototype
ConcreteFactory
ProductA
ProductB
ConcreteBuilder
ConcreteProduct
ConcretePrototype
9. Decorator
Client
Client
Client
Director
Creator
Client
Singleton
Client
Client
Abstraction
Client
Composite
Decorator
Target
Abstraction
Implementor
Component
Component
Component
Adapter
RefinedAbstarction
ConcreteImplementor
Leaf Composite
Leaf Composite
ConcreteComponent
Decorator
10. Faade
11. Flyweight
main
FlyweightFactory
Faade
Flyweight
12. Proxy
13. Chain of
Responsibility
14. Command
15. Interpreter
Client
Client
Handler
Invoker
Client
Subject
Handler
Handler
Command
AbstractExpression
NonterminalExpre
ssion
AbstractExpression
Client
Client
Colleague
CareTaker
Subject
Context
Context
Client
Client
ObjectStructure
Aggregate
Iterator
Mediator
Memento
Observer
State
Strategy
AbstractClass
Visitor
Element
1. Abstract Factory
2. Builder
3. Factory Method
4. Prototype
5. Singleton
6. Adapter
7. Bridge
8. Composite
ConcreteFlyweighti
Category presence of
BDPSS
Wholly more BDPSS
UnsharedConcreteFlyweight
16. Iterator
17. Mediator
18. Memento
19.Observer
20. State
21. Strategy
22. Template Method
23. Visitor
Proxy RealSubject
ConcreteHandler
ConcreteHandler
ConcreteCommand
TerminalExpression
NonterminalExpression
TerminalExpression
NonterminalExpression
ConcreteAggregate
ConcreteIterator
ConcreteMediator
ConcreteObserver
ConcreteState
ConcreteStrategy
ConcreteClass
ConcreteVisitor
ConcreteElementi
15
and
Client
=
NoterminalExpression,
AbstractServer
=
AbstractExpression and ConcreteSever = ConcreteExpression.
ConcreteExpression
NoterminalExpression.
are
TerminalExpression
and
Abstraction
and
ConcreteImplementorA
and
16
class Main
{ public static void main(String arg[])
{ CL cl = new CL();
int cs;
if (arg[0].equals(cs1))
cs = 1;
if (arg[0].equals(cs2)
cs = 2;
...
if (arg[0].equals(csn)
cs = n;
CS1
CL
CS2
CSn
cl.request(cs);
(Cl has CS1 )and(Cl has CS2 ) and ... and (Cl has CSn )
class CL
{ CS1 cs1; Cs2 cs2; ... CSn csn; ...
class CL
{ CS1 cs1; Cs2 cs2; ... CSn csn; ...
CL( ) { cs1 = new CS1(); cs2 = new CS2(); ...
csn= new CSn(); ... }
void request (int cs)
{
if (cs==1) {cs1.request();}
if (cs==2) {cs2.request();}
...
if (cs==n) {csn.request();}
}
... }
if (cs==2) {cs2.request();}
...
if (cs==n) {csn.request();}
if (cs==n+1) {csn+1.request();}// change of the Client
}
... }
17
V.
Design problem-BDPSP
Design solution-BDPSS
CS1
Cl
AS
Cl
CS2
CS1
CSn
CS2
CSn
I = Ce/(Ca+Ce),
where is I mark for instability. Ca is afferent couplings, i.e. the
number of classes outside this component that depend on
classes within this component. Ce is efferent couplings, i.e. the
number of classes inside this component that depend on classes
outside this component. Stability metric has the range [0,1].
18
REFERENCES
VI. CONCLUSION
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
19
Duan Savi received the Magistar degree in Information system and technologies from the Faculty
of Organization Sciences, University of Belgrade, in 2010. He is currently postgraduate student and
teaching assistant on Faculty of Organizational Sciences at the Software Engineering Department.
He has interests in the following areas: Modeling and Meta-modeling, Model Driven Engineering,
Requirement Engineering, Software Development, Software Design, Domain Specific Languages,
Automation of User Interface development. He has taught undergraduate and graduate level courses
in his area. He is the author or co-author of several publications on national and international
conference and workshop and journal papers.
Milo Mili is teaching assistant at Faculty of Organizational Sciences, University of Belgrade,
Serbia. He has taught undergraduate and graduate level courses: introduction to programming,
software design, software patterns and Java programming language. His research interests include
Software Quality, Software Design and Software Testing. He holds BSc in Information Systems and
MSc in Software Engineering. He is PhD student at University of Belgrade
PhD Ilija Antovi is an assistant professor of software engineering at University of Belgrade, Faculty
of Organizational Sciences, Department of Information Systems. His research interests are:
Automation of User Interface development, Modeling and Meta-modeling, Model Driven
Engineering, Requirements Engineering, Software patterns, Code Generation. He lectures at
undergraduate and graduate level courses in his area. He is the author or co-author of several
publications on national and international conferences and journal papers.
20