More Related Content
Similar to Lecture12 (20)
Lecture12
- 1. Computer Engineering Department
Object Oriented Software
Modeling and Design
CE 350
Abdel-Karim Al-Tamimi, Ph.D.
altamimi@yu.edu.jo
http://faculty.yu.edu.jo/altamimi
Al-Tamimi 2011 © 1
- 2. Overview
• Design Patterns
– Proxy Design Pattern (Structural)
– Interpreter Design Pattern (Behavioral)
• Anti-Patterns
Al-Tamimi 2011 © 2
- 3. Proxy Design Pattern
• Problem: You need to support resource-
hungry objects, and you do not want to
instantiate such objects unless and until
they are actually requested by the client
• Solution: Provide a surrogate or
placeholder for another object to control
access to it
Al-Tamimi 2011 © 3
- 4. Proxy Design Pattern
• Use an extra level of indirection to support
distributed, controlled, or
intelligent access
• Add a wrapper and delegation to protect
the real component from
undue complexity
Al-Tamimi 2011 © 4
- 5. Proxy Pattern Common Situations
• A virtual proxy is a placeholder for
“expensive to create” objects. The real
object is only created when a client first
requests/accesses the object
• A remote proxy provides a local
representative for an object that resides in
a different address space
Al-Tamimi 2011 © 5
- 6. Proxy Pattern Common Situations
• A protective proxy controls access to a sensitive master
object. The “surrogate” object checks that the caller has
the access permissions required prior to forwarding
the request
• A smart proxy interposes additional actions when an
object is accessed. Typical uses include:
– Counting the number of references to the real object so that it
can be freed automatically when there are no more references
(aka smart pointer)
– Loading a persistent object into memory when it’s
first referenced
– Checking that the real object is locked before it is accessed to
ensure that no other object can change it
Al-Tamimi 2011 © 6
- 8. Proxy Pattern: Example
• The Proxy provides a surrogate or place
holder to provide access to an object.
• A check or bank draft is a proxy for funds
in an account.
• A check can be used in place of cash for
making purchases and ultimately controls
access to cash in the issuer’s account.
Al-Tamimi 2011 © 8
- 10. Proxy Pattern: Implementation
// "Subject"
abstract class Subject Subject
{
public abstract void Request();
}
// "RealSubject"
class RealSubject : Subject
{
public override void Request()
{
Console.WriteLine("Called RealSubject.Request()");
}
}
Al-Tamimi 2011 © 10
- 11. Proxy Pattern: Implementation
// "Proxy"
class Proxy : Subject Proxy
{
RealSubject realSubject;
public override void Request()
{
// Use 'lazy initialization'
if (realSubject == null)
{
realSubject = new RealSubject();
}
realSubject.Request();
}
}
Al-Tamimi 2011 © 11
- 12. Proxy Pattern: Implementation
Using Proxy Pattern
static void Main()
{
// Create proxy and request a service
Proxy proxy = new Proxy();
proxy.Request();
}
Al-Tamimi 2011 © 12
- 13. Interpreter Design Pattern
• Problem: A class of problems occurs repeatedly in a
well-defined and well-understood domain. If the
domain were characterized with a “language”, then
problems could be easily solved with an
interpretation “engine”
• Solution: Given a language, define a representation
for its grammar along with an interpreter that uses the
representation to interpret sentences in the language
• Map a domain to a language, the language to a
grammar, and the grammar to a hierarchical object-
oriented design
Al-Tamimi 2011 © 13
- 15. Interpreter Pattern: Example
• The interpreter pattern defines a grammatical
representation for a language and an interpreter
to interpret the grammar
• Musicians are examples of Interpreters. The
pitch of a sound and its duration can be
represented in musical notation on a staff.
♫
• This notation provides the language of music.
Musicians playing the music from the score are
able to reproduce the original pitch and duration
of each sound represented.
Al-Tamimi 2011 © 15
- 17. Interpreter Pattern: Implementation
// "AbstractExpression"
abstract class AbstractExpression Expressions
{
public abstract void Interpret(Context context);
}
// "TerminalExpression"
class TerminalExpression : AbstractExpression
{
public override void Interpret(Context context)
{
Console.WriteLine("Called Terminal.Interpret()");
}
}
// "NonterminalExpression"
class NonterminalExpression : AbstractExpression
{
public override void Interpret(Context context)
{
Console.WriteLine("Called Nonterminal.Interpret()");
}
}
Al-Tamimi 2011 © 17
- 18. Interpreter Pattern: Implementation
static void Main()
{ Using Interpreter Pattern
Context context = new Context();
// Usually a tree
ArrayList list = new ArrayList();
// Populate 'abstract syntax tree'
list.Add(new TerminalExpression());
list.Add(new NonterminalExpression());
list.Add(new TerminalExpression());
list.Add(new TerminalExpression());
// Interpret
foreach (AbstractExpression exp in list)
{
exp.Interpret(context);
}
}
Al-Tamimi 2011 © 18
- 20. Anti-Patterns
• An Anti-pattern is a literary form that describes
a commonly occurring solution to a problem that
generates decidedly negative consequences
• The Anti-pattern may be the result of a manager
or developer not knowing any better, not having
sufficient knowledge or experience in solving a
particular type of problem, or having applied a
perfectly good pattern in the wrong context
Al-Tamimi 2011 © 20
- 21. Software Development Anti-patterns
• A key goal of development
Anti-patterns is to describe
useful forms of software
refactoring
• Software refactoring is a
form of code modification,
used to improve the
software structure in
support of subsequent
extension and long-term
maintenance.
• In most cases, the goal is to
transform code without
impacting correctness
Al-Tamimi 2011 © 21
- 22. The Blob
• Procedural-style design
leads to one object with a
lion’s share of the
responsibilities, while
most other objects only
hold data or execute
simple processes.
• The solution includes
refactoring the design to
distribute responsibilities
more uniformly and
isolating the effect
of changes.
Al-Tamimi 2011 © 22
- 24. Continuous Obsolescence
• Technology is changing so
rapidly that developers have
trouble keeping up with the
current versions of software
and finding combinations of
product releases that
work together
• Architects and developers
should depend upon interfaces
that are stable or that they
control. Open systems
standards give a measure of
stability to an otherwise
chaotic technology market.
Al-Tamimi 2011 © 24
- 25. Functional Decomposition
• Happens when non-object-oriented
developers design and implement an
application in an object-oriented language
• They may tend to make every subroutine a
class, ignoring class hierarchy altogether
• This is due to: Lack of object-oriented
understanding, Lack of architecture
enforcement, and/or specification
disasters
Al-Tamimi 2011 © 25
- 26. Functional Decomposition: Solution
• If the class has a single method, try to
better model it as part of an existing class
• Attempt to combine several classes into a
new class that satisfies a design objective
– You might consider hierarchy
• If the class does not contain state
information of any kind, consider
rewriting it as a function
– Or use singleton pattern
Al-Tamimi 2011 © 26