Cursul 6 – 26 Martie 2018 [email protected]
Din Cursurile trecute…
SOLID Principles
Design Patterns
◦ Definitions
◦ Elements
◦ Example
◦ Classification
JUnit Testing
◦ Netbeans (Exemplu 1)
◦ Eclipse (Exemplu 2)
2
Etapele Dezvoltării Programelor
Ingineria Cerinţelor
Diagrame UML
GRASP
Principii, responsabilități
Information Expert
Creator
Low Coupling
High Cohesion
Controller
4
SOLID Principles
◦ SRP – Single Responsibility Principle
◦ OCP – Open/Closed Principle
◦ LSP – Liskov Substitution Principle
◦ ISP – Interface Segregation Principle
◦ DIP – Dependency Inversion Principle
DRY – Don't Repeat Yourself
YAGNI – You Aren't Gonna Need It
KISS – Keep It Simple, Stupid
SOLID was introduced by Robert C. Martin in the an article called the “Principles of Object Oriented
Design” in the early 2000s
6
Every object should have a single responsibility, and all its services should be narrowly aligned with that responsibility
“The Single Responsibility Principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.” – Wikipedia
“There should never be more than one reason for a class to change.” - Robert Martin
Low coupling & strong cohesion
8
Classic violations
◦ Objects that can print/draw themselves
◦ Objects that can save/restore themselves
Classic solution
◦ Separate printer & Separate saver
Solution
◦ Multiple small interfaces (ISP)
◦ Many small classes
◦ Distinct responsibilities
Result
◦ Flexible design
◦ Lower coupling & Higher cohesion
Two responsabilities
Separated interfaces
interface Modem {
public void dial(String pno);
public void hangup();
public void send(char c);
public char recv();
}
interface DataChannel { public void send(char c);
public char recv();
}
interface Connection {
public void dial(String phn);
public char hangup();
}
10
Open chest surgery is not needed when putting on a coat
Bertrand Meyer originated the OCP term in his 1988 book, Object Oriented Software Construction
“The Open / Closed Principle states that software
entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.” – Wikipedia
“All systems change during their life cycles. This must be borne in mind when developing systems expected to last longer than the first version.” - Ivar Jacobson
Open to Extension - New behavior can be added in the future
Closed to Modification - Changes to source or binary code are not required
12
Change behavior without changing code?!
◦ Rely on abstractions, not implementations
◦ Do not limit the variety of implementations
In .NET – Interfaces, Abstract Classes
In procedural code - Use parameters
Approaches to achieve OCP
◦ Parameters - Pass delegates / callbacks
◦ Inheritance / Template Method pattern - Child types override behavior of a base class
◦ Composition / Strategy pattern - Client code depends on abstraction, "Plug in" model
Classic violations
◦ Each change requires re-testing (possible bugs)
◦ Cascading changes through modules
◦ Logic depends on conditional statements
Classic solution
◦ New classes (nothing depends on them yet)
◦ New classes (no legacy coupling)
When to apply OCP?
◦ Experience tell you
OCP add complexity to design (TANSTAAFL)
No design can be closed against all changes
14
// Open-Close Principle - Bad example class GraphicEditor {
public void drawShape(Shape s) { if (s.m_type==1)
drawRectangle(s);
else if (s.m_type==2) drawCircle(s);
}
public void drawCircle(Circle r) {....}
public void drawRectangle(Rectangle r) {....}
}
class Shape { int m_type;
}
class Rectangle extends Shape { Rectangle() {super.m_type=1;}
}
class Circle extends Shape {
// Open-Close Principle - Good example
class GraphicEditor {
public void drawShape(Shape s) { s.draw();
} }
class Shape {
abstract void draw();
}
class Rectangle extends Shape { public void draw() {
// draw the rectangle }
}
If it looks like a duck, quacks like a duck, but needs batteries – you probably have the wrong abstraction
Barbara Liskov described the principle in 1988
16
"The Liskov Substitution Principle states that Subtypes must be substitutable for their base
types.“ - Agile Principles, Patterns, and Practices in C#
Substitutability – child classes must not
◦ Remove base class behavior
◦ Violate base class invariants
Normal OOP inheritance
◦ IS-A relationship
Liskov Substitution inheritance
◦ IS-SUBSTITUTABLE-FOR
The problem
◦ Polymorphism break Client code expectations
◦ "Fixing" by adding if-then – nightmare (OCP)
Classic violations
◦ Type checking for different methods
◦ Not implemented overridden methods
◦ Virtual methods in constructor
Solutions
◦ “Tell, Don’t Ask” - Don’t ask for types and Tell the object what to do
◦ Refactoring to base class- Common functionality and Introduce third class
18
// Violation of Liskov's Substitution Principle class Rectangle{
int m_width;
int m_height;
public void setWidth(int width){
m_width = width;
}
public void setHeight(int h){
m_height = ht;
}
public int getWidth(){
return m_width;
}
public int getHeight(){
return m_height;
}
public int getArea(){
return m_width * m_height;
class Square extends Rectangle { public void setWidth(int width){
m_width = width;
m_height = width;
}
public void setHeight(int height){
m_width = height;
m_height = height;
} }
class LspTest
{private static Rectangle getNewRectangle()
{ // it can be an object returned by some factory ...
return new Square();
}
public static void main (String args[])
{ Rectangle r = LspTest.getNewRectangle();
r.setWidth(5);
r.setHeight(10);
// user knows that r it's a rectangle. It assumes that he's able to set the width and height as for the base class
System.out.println(r.getArea());
// now he's surprised to see that the area is 100 instead of 50.
}}
20
You want me to plug this in. Where?
“The Interface Segregation Principle states that
Clients should not be forced to depend on methods they do not use.” - Agile Principles, Patterns, and Practices in C#
Prefer small, cohesive interfaces - Interface is the interface type + All public members of a class
Divide "fat" interfaces into smaller ones
◦ “fat” interfaces means classes with useless methods,
increased coupling, reduced flexibility and maintainability
22
Classic violations
◦ Unimplemented methods (also in LSP)
◦ Use of only small portion of a class
When to fix?
◦ Once there is pain! Do not fix, if is not broken!
◦ If the "fat" interface is yours, separate it to smaller ones
◦ If the "fat" interface is not yours, use "Adapter" pattern
Solutions
◦ Small interfaces
◦ Cohesive interfaces
◦ Focused interfaces
◦ Let the client define interfaces
◦ Package interfaces with their implementation
//Bad example (polluted interface)
interface Worker { void work();
void eat();
}
ManWorker implements Worker { void work() {…};
void eat() {30 min break;};
}
RobotWorker implements Worker { void work() {…};
void eat() {//Not Appliciable for a RobotWorker};
}
//Solution: split into two interfaces
interface Workable {
public void work();
}
interface Feedable{
public void eat();
}
24
Would you solder a lamp directly to the electrical wiring in a wall?
“High-level modules should not depend on low-level modules. Both should depend on abstractions.”
“Abstractions should not depend on details.
Details should depend on abstractions.” -
Agile Principles, Patterns, and Practices in C#
26
Framework
Third Party Libraries
Database
File System
Web Services
System Resources (Clock)
Configuration
The new Keyword
Static methods
Thread.Sleep
Random
How it should be
◦ Classes should declare what they need
◦ Constructors should require dependencies
◦ Dependencies should be abstractions and be shown
How to do it
◦ Dependency Injection
◦ The Hollywood principle "Don't call us, we'll call you!"
Classic violations
◦ Using of the new keyword, static methods/properties
How to fix?
◦ Default constructor, main method/starting point
◦ Inversion of Control container
28
//DIP - bad example
public class EmployeeService {
private EmployeeFinder emFinder //concrete class, not abstract. Can access a SQL DB for instance public Employee findEmployee(…) {
emFinder.findEmployee(…)
} }
//DIP - fixed
public class EmployeeService {
private IEmployeeFinder emFinder //depends on an abstraction, no an implementation public Employee findEmployee(…) {
emFinder.findEmployee(…) }
}
//Now its possible to change the finder to be a XmlEmployeeFinder, DBEmployeeFinder, FlatFileEmployeeFinder, MockEmployeeFinder….
Don't Repeat Yourself (DRY)
You Ain't Gonna Need It (YAGNI)
Keep It Simple, Stupid (KISS)
30
Repetition is the root of all software evil
"Every piece of knowledge must have a single, unambiguous representation in the system.“
- The Pragmatic Programmer
"Repetition in logic calls for abstraction.
Repetition in process calls for automation.“ - 97 Things Every Programmer Should Know
Variations include:
◦ Once and Only Once
◦ Duplication Is Evil (DIE)
32
Magic Strings/Values
Duplicate logic in multiple locations
Repeated if-then logic
Conditionals instead of polymorphism
Repeated Execution Patterns
Lots of duplicate, probably copy-pasted, code
Only manual tests
Static methods everywhere
Don’t waste resources on what you might need
34
"A programmer should not add functionality until deemed necessary.“ – Wikipedia
"Always implement things when you actually need them, never when you just foresee that you need them.“ - Ron Jeffries, XP co-founder
Time for adding, testing, improving
Debugging, documented, supported
Difficult for requirements
Larger and complicate software
May lead to adding even more features
May be not know to clients
36
You don’t need to know the entire universe when living on the Earth
"Most systems work best if they are kept simple.“ - U.S. Navy
"Simplicity should be a key goal in design and unnecessary complexity should be avoided.“
- Wikipedia
38
If a problem occurs over and over again, a solution to that problem has been used
effectively (solution = pattern)
When you make a design, you should know the names of some common solutions. Learning
design patterns is good for people to communicate each other effectively
“Design patterns capture solutions that have
developed and evolved over time” (GOF - Gang-Of- Four (because of the four authors who wrote it), Design Patterns: Elements of Reusable Object- Oriented Software)
In software engineering (or computer science), a design pattern is a general repeatable solution to a commonly occurring problem in software design
The design patterns are language-independent strategies for solving common object-oriented design problems
40
Initial was the name given to a leftist political
faction composed of four Chinese Communist party officials
The name of the book (“Design Patterns: Elements of Reusable Object-Oriented Software”) is too long for e-mail, so “book by the gang of four” became a shorthand name for it
That got shortened to "GOF book“. Authors are:
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
The design patterns in their book are descriptions of communicating objects and classes that are
customized to solve a general design problem in a particular context
1.
Pattern name
2.
Problem
3.
Solution
4.
Consequences
42
A handle used to describe a design problem, its solutions, and consequences in a word or two
Naming a pattern immediately increases our design vocabulary. It lets us design at a higher level of abstraction
Having a vocabulary for patterns lets us talk about them with our colleagues, in our
documentation
Finding good names has been one of the
hardest parts of developing our catalog
Describes when to apply the pattern. It explains the problem and its context
It might describe specific design problems such as how to represent algorithms as
objects
It might describe class or object structures that are symptomatic of an inflexible design
Sometimes the problem will include a list of conditions that must be met before it makes sense to apply the pattern
44
Describes the elements that make up the design, their relationships, responsibilities, and
collaborations
The solution doesn’t describe a particular
concrete design or implementation, because a pattern is like a template that can be applied in many different situations
Instead, the pattern provides an abstract description of a design problem and how a
general arrangement of elements (classes and objects in our case) solves it
Are the results and trade-offs of applying the pattern
They are critical for evaluating design alternatives and for understanding the costs and benefits of applying the pattern
The consequences for software often concern space and time trade-offs, they can address language and implementation issues as well
Include its impact on a system's flexibility, extensibility, or portability
Listing these consequences explicitly helps you understand and evaluate them
46
Pattern name: Initialization
Problem: It is important for some code
sequence to be executed only once at the beginning of the execution of the program.
Solution: The solution is to use a static variable that holds information on whether or not the
code sequence has been executed.
Consequences: The solution requires the
language to have a static variable that can be allocated storage at the beginning of the
execution, initialized prior to the execution and
remain allocated until the program termination.
Pattern Name and Classification
Intent - the answer to question:
What does the design pattern do
? Also Known As
Motivation - A scenario that illustrates a design
problem and how the class and object structures in the pattern solve the problem
Applicability -
What are the situations in which the design pattern can be applied
?How can you
recognize these situations
? Related Patterns
48
Structure - A graphical representation of the classes in the pattern
Participants - The classes and/or objects participating in the design pattern and their responsibilities
Collaborations - How the participants collaborate to carry out their responsibilities
Consequences - How does the pattern support its objectives?
Implementation – What techniques should you be aware of when implementing the pattern?
Sample Code
Known Uses - Examples of the pattern found in real systems
Creational patterns
Structural patterns
Behavioral patterns
NOT in GOF: Fundamental, Partitioning, GRASP, GUI, Organizational Coding, Optimization
Coding, Robustness Coding, Testing, Transactions, Distributed Architecture,
Distributed Computing, Temporal, Database, Concurrency patterns
50
Abstract Factory groups object factories that have a common theme
Builder constructs complex objects by separating construction and representation
Factory Method creates objects without specifying the exact class to create
Prototype creates objects by cloning an existing object
Singleton restricts object creation for a class to only one instance
Not in GOF book: Lazy initialization, Object pool,
Adapter allows classes with incompatible interfaces to work together
Bridge decouples an abstraction from its
implementation so that the two can vary independently
Composite composes zero-or-more similar objects so that they can be manipulated as one object.
Decorator dynamically adds/overrides behavior in an existing method of an object
Facade provides a simplified interface to a large body of code
Flyweight reduces the cost of creating and
manipulating a large number of similar objects
Proxy provides a placeholder for another object to control access, reduce cost, and reduce complexity
52
Chain of responsibility delegates commands to a chain of processing objects
Command creates objects which encapsulate actions and parameters
Interpreter implements a specialized language
Iterator accesses the elements sequentially
Mediator allows loose coupling between classes by being the only class that has detailed knowledge of their methods
Memento provides the ability to restore an object to its previous state
Observer allows to observer objects to see an event
State allows an object to alter its behavior when its internal state changes
Strategy allows one of a family of algorithms to be selected on-the-fly at runtime
Template defines an algorithm as an abstract class, allowing its subclasses to provide concrete
behavior
Visitor separates an algorithm from an object structure
Not in GOF book: Null Object, Specification
54
Patterns
Creational
Structural
Behavioral
With more than 20 design patterns to choose from, it might be hard to find the one that addresses a
particular design problem
Approaches to finding the design pattern that’s right for your problem:
1. Consider how design patterns solve design problems 2. Scan Intent sections
3. Study relationships between patterns
4. Study patterns of like purpose (comparison) 5. Examine a cause of redesign
6. Consider what should be variable in your design
56
1.
Read the pattern once through for an overview
2.
Go back and study the Structure
, Participants, and Collaborations sections3.
Look at the Sample Code section to see a concrete example
4.
Choose names for pattern participants that are meaningful in the application context
5.
Define the classes
6.
Define application-specific names for operations in the pattern
7.
Implement the operations to carry out the
Testarea unei funcţii, a unui program, a unui ecran, a unei funcţionalităţi
Se face de către programatori
Predefinită
Rezultatele trebuie documentate
Se folosesc simulatoare pentru Input şi Output
58
60
62
64
66
68
NetBeans - TikiOne JaCoCoverage:
http://plugins.netbeans.org/plugin/48570/tikio ne-jacocoverage
Java Code Coverage for Eclipse:
http://www.eclemma.org/
IntelliJ – Running with coverage:
https://www.jetbrains.com/help/idea/2016.3/r unning-with-coverage.html
70
72
SOLID
Design Patterns
◦ Definitions, Elements, Example, Classification
JUnit Testing
1) Argumentați pentru folosirea DP.
2) Argumentați pentru folosirea diagramelor.
3) Veniți cu argumente pentru a nu folosi diagrame sau DP.
Criticism:
http://sourcemaking.com/design_patterns
74
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides:
Design Patterns: Elements of
Reusable Object-Oriented Software
(GangOfFour) Ovidiu Gheorghieş, Curs 7 IP
Adrian Iftene, Curs 9 TAIP:
http://thor.info.uaic.ro/~adiftene/Scoala/2011/
TAIP/Courses/TAIP09.pdf
Gang-Of-Four: http://c2.com/cgi/wiki?GangOfFour,
http://www.uml.org.cn/c%2B%2B/pdf/DesignPatterns.pdf
Design Patterns Book: http://c2.com/cgi/wiki?DesignPatternsBook
About Design Patterns: http://www.javacamp.org/designPattern/
Design Patterns – Java companion:
http://www.patterndepot.com/put/8/JavaPatterns.htm
Java Design patterns:
http://www.allapplabs.com/java_design_patterns/java_design_patter ns.htm
Overview of Design Patterns:
http://www.mindspring.com/~mgrand/pattern_synopses.htm
Gang of Four: http://en.wikipedia.org/wiki/Gang_of_four
JUnit in Eclipse: http://www.vogella.de/articles/JUnit/article.html
JUnit in NetBeans: http://netbeans.org/kb/docs/java/junit-intro.html
76
