Conception Orientée Objets. Programmation SOLID

Similar documents
Design Principles: Part 2

Outline. Design Principles: Part 2. e.g. Rectangles and Squares. The Liskov Substitution Principle (LSP) ENGI 5895: Software Design.

Design Principles: Part 2

S.O.L.I.D: Software Engineering Principles

Ingegneria del Software Corso di Laurea in Informatica per il Management. Software quality and Object Oriented Principles

OOD Smells and Principles

Single Responsibility Principle (SRP)

Open Closed Principle (OCP)

Principles of OO Design

OO Class Design Principles

17.11 Bean Rules persistent

Software Engineering

Software Engineering CSC40232: SOFTWARE ENGINEERING. Guest Lecturer: Jin Guo SOLID Principles sarec.nd.edu/courses/se2017

Outline. Software Rots

The Liskov Substitution Principle

Object Oriented Software Design - I

SOLID Principles. Equuleus Technologies. Optional Subheading October 19, 2016

Software Engineering Design & Construction

Software Engineering I (02161)

Liskov Substitution Principle

Bruno Bossola SOLID Design Principles

Object-oriented design principles

Highlights of Previous Lecture

Produced by. Agile Software Development. Eamonn de Leastar

CHAPTER 5: PRINCIPLES OF DETAILED DESIGN

Last Time: Object Design. Comp435 Object-Oriented Design. Last Time: Responsibilities. Last Time: Creator. Last Time: The 9 GRASP Patterns

Agile Software Development

SOLID: Principles of OOD

S Single Responsability Principle

Class Design Principles

CSC207H: Software Design SOLID. CSC207 Winter 2018

Component-Level Design

CSC 160 LAB 8-1 DIGITAL PICTURE FRAME. 1. Introduction

Principles of Object-Oriented Design

Single Responsibility Principle

Course 2 October, 16, Adrian Iftene

COURSE 2 DESIGN PATTERNS

Software Design and SOLID Principles

Contents. Unpleasant Code Smells. Refactoring

Outline. Inheritance. Abstract Classes Interfaces. Class Extension Overriding Methods Inheritance and Constructors Polymorphism.

Chapter 6: Inheritance

Outline. Subtype Polymorphism, Subtyping vs. Subclassing, Liskov Substitution Principle. Benefits of Subtype Polymorphism. Subtype Polymorphism

Testing Object-Oriented Software. 22 November 2017

Proctors are unable to respond to queries about the interpretation of exam questions. Do your best to answer exam questions as written.

n HW5 out, due Tuesday October 30 th n Part 1: Questions on material we ll cover today n Part 2: BFS using your graph from HW4

Software Engineering Design & Construction Dr. Michael Eichberg Fachgebiet Softwaretechnik Technische Universität Darmstadt

On Polymorphism and the Open-Closed Principle

For this section, we will implement a class with only non-static features, that represents a rectangle

11/2/09. Code Critique. What goal are we designing to? What is the typical fix for code smells? Refactoring Liskov Substitution Principle

Refactoring Without Ropes

Agile Principles, Patterns, and Practices in C#

S.O.L.I.D. Principles of

Software Engineering Design & Construction

Principles of Ruby Applica3on Design. Dean Wampler Senior Mentor and Consultant Object Mentor, Inc. Chicago, IL

The following topics will be covered in this course (not necessarily in this order).

AP CS Unit 11: Graphics and Events

Cursul 6 27 Martie 2017

Build Testable Client and Service Applications

Software Engineering Design & Construction Dr. Michael Eichberg Fachgebiet Softwaretechnik Technische Universität Darmstadt

CS 520 Theory and Practice of Software Engineering Fall 2017

Object-Oriented Design I - SOLID

11/4/15. Review. Objec&ves. Refactoring for Readability. Review. Liskov Subs&tu&on Principle (LSP) LISKOV SUBSTITUTION PRINCIPLE

Intro to: Design Principles

Proctors are unable to respond to queries about the interpretation of exam questions. Do your best to answer exam questions as written.

Test, Code, Design: Inverting the Waterfall

Index. Index. More information. block statements 66 y 107 Boolean 107 break 55, 68 built-in types 107

20 Years of. Improve the Design of your Code. Dr Dimitris Dranidis JAVA Meetup Group, Thessaloniki May 2015

Lessons Learned. Johnny Bigert, Ph.D., Skype/Microsoft October 26, 2011

Midterm assessment - MAKEUP Fall 2010

First Name: AITI 2004: Exam 2 July 19, 2004

Software Engineering Design & Construction

On Polymorphism and the Open-Closed Principle

On to Object-oriented Design

CS 520 Theory and Practice of Software Engineering Fall 2018

Test Code Patterns. How to design your test code

ITI Introduction to Computing II

6.170 Recitation #5: Subtypes and Inheritance

ITI Introduction to Computing II

Testing and Inheritance. Test Code Patterns. Inheritance-related bugs. Inheritance. Testing of Inheritance. Inheritance-related bugs

OO Design Principles

Computer Science 210: Data Structures

Lecture: Modular Design

Subtypes and Subclasses

Object-Oriented Design

Design Patterns: Part 2

The S.O.L.I.D. Principles. of Object Oriented Programming

First Name: AITI 2004: Exam 2 July 19, 2004

IS-A / HAS-A. I IS-A Teacher and I HAS-A Laptop

09. Component-Level Design

Object Oriented Programming and Design in Java. Session 10 Instructor: Bert Huang

CPSC 410? Advanced Software Engineering Mid-term Examination (Term I ) SOLUTION Instructor: Gail Murphy

Plan. Design principles: laughing in the face of change. What kind of change? What are we trying to achieve?

2. (True/False) All methods in an interface must be declared public.

Introduction to Testing and Maintainable code

EasyChair Preprint. Software Metrics Proposal for Conformity Checking of Class Diagram to SOLID Design Principles

Proctors are unable to respond to queries about the interpretation of exam questions. Do your best to answer exam questions as written.

CSE wi Final Exam 3/12/18 Sample Solution

COMP 401 Fall Recitation 6: Inheritance

COMP 249: Object Oriented Programming II. Tutorial 2: Intro to Inheritance

Software Engineering Design & Construction Dr. Michael Eichberg Fachgebiet Softwaretechnik Technische Universität Darmstadt

Transcription:

Conception Orientée Objets Programmation SOLID Frédéric Mallet http://deptinfo.unice.fr/~fmallet/ F. Mallet SOLID 1

Objectives Introduce some principles to guide the design Single responsibility Open Closed (Liskov) Substitution Interface Dependency inversion See Robert Martin s book Agile Software Development: Principles, Patterns and Practices, Prentice Hall F. Mallet SOLID 2

Single Responsibility Principle A class should have one, and only one, reason to change. Shared responsibilities means Coupling the responsibilities: Changes on one responsibility may impact the other one; The need to rebuild, retest, repackage everything at each change. Limit reusability; Combining the dependencies. Warning: avoid needless complexity Some responsibilities may actually be intrinsically coupled! F. Mallet SOLID 3

SRP: One example of coupling A rectangle can be A mathematical object for computational geometry; A figure to be drawn in a GUI F. Mallet SOLID 4

SRP: One example of decoupling A rectangle can be A mathematical object for computational geometry; A figure to be drawn in a GUI F. Mallet SOLID 5

SRP and Interfaces SRP violation A Modem Handles connection Send/receive information Decoupled if necessary How to decouple? connection communication F. Mallet SOLID 6

SRP: General comments Avoid coupling as much as possible Testing is easier when coupling is minimal Two places where decoupling is essential Graphical interface Separate business model from the layout (e.g. MVC) Persistence Separate the business model from the technology to save/restore objects on disk F. Mallet SOLID 7

Closed to modification SOLID Open Closed Encapsulation allows to control the modifications from the other classes Want to limit the changes in the existing code Open for extensions Requirements are meant to evolve all the time Should easy allow extensions By adding new classes, not modifying existing ones The behavior of a module evolves without changing the module code (untouched.dll,.jar) F. Mallet SOLID 8

Symptom SOLID Open Closed Principle A single change results in a cascade of changes in dependent modules Design Smell: Rigidity Diagnostic Refactor your design to avoid such cascades If OCP is applied well add new code, not changing old code F. Mallet SOLID 9

OCP: violated Simple example of violation Client Server Any modification on the server impacts the client At the very least needs to recompile F. Mallet SOLID 10

OCP: fixing the violation Simple example of violation Client Server Any modification on the server impacts the client At the very least needs to recompile Simple fix of the violation: Strategy Pattern Introduce an abstract interface that serves the client Client «interface» ClientInterface Server F. Mallet SOLID 11

OCP: fixing the violation Simple example of violation Client Server Other fix of the violation: Abstract Method Pattern Introduce an abstract method that can evolve Client «abstract» AServer + serve() # doservice() Server # doservice() F. Mallet SOLID 12

OCP: fixing the violation Simple example of violation Client Other fix of the violation: Client Strategy Pattern Server «interface» ClientInterface + serve() Server + serve() Strategy Pattern «interface» Service + doservice() Service1 + doservice() F. Mallet SOLID 13

Where to stop? It depends Take the first bullet SOLID OCP If you meet a case, where you cannot easily extend Then you build a more general mechanism Beware of antipatterns Bring accidental complexity F. Mallet SOLID 14

Liskov substitution principle OCP relies on abstraction and polymorphism Inheritance is a way to achieve abstraction and polymorphism Liskov substitution principle (LSP) Gives a rule to decide how to build a sound inheritance tree Subtypes must be substitutable for their base types F. Mallet SOLID 15

Scenario Violation Given a method SOLID LSP f(b: BaseType) Apply f to an object d of type DerivativeType such that DerivativeType inherits from BaseType This causes f to fail Fix f by testing the dynamic type of b This causes an OCP violation => When creating other derivatives of BaseType, it is possible that f will also misbehave Ex: If (b instanceof DerivativeType) LSP violation has caused an OCP violation F. Mallet SOLID 16

LSP: Examples Can we use inheritance to unify those classes? Rectangle width : int height : int + setwidth(int) + setheight(int) + getwidth() : int + getheight() : int + area() side : int Square + setside(int) + getside() : int + area() p1 : Point p2 : Point Line + getslope() : int + getintercept() : Point + ison(point) : boolean p1 : Point p2 : Point LineSegment + getslope() : int + getintercept() : Point + ison(point) : boolean + getlength() : int F. Mallet SOLID 17

Can we use inheritance? It depends (see Code) Rectangle and Square SOLID LSP: Examples setwidth(int) implicitly assumes that it does not alter height Line and LineSegment Line assumes line.ison(line.getintercept()) May introduce a LinearObject F. Mallet SOLID 18

LSP: general rules When to use inheritance? When two classes share a common responsibility Build a super class in charge of this responsibility Beware of pre and post conditions when overriding May only replace a precondition by one equal or weaker May only replace a post condition by one equal or stronger Rectangle.setWidth: post condition: this.width == width && this.height == old.height Square.setWidth: post condition: this.width == width [weaker] Should not (in general) remove functionality Beware of degenerative functions [D extends B] B.f() { /* some code */ } D.f() { /* empty */ } F. Mallet SOLID 19

Dependency Inversion Principle High level modules should not depend on Low Level Modules This is contrary to usual functional decomposition Both should depend on abstractions Abstractions should not depend on details Details should depend on abstractions F. Mallet SOLID 20

DIP Broken SOLID Dependency Inversion Principle DIP fixed UtilityAPI Utility Adapter Adapter Pattern F. Mallet SOLID 21

Copy SOLID DIP: Example void copy() throws IOException { for (int c = System.in.read(); c!= -1; c = System.in.read()) { System.out.write(c); } } High level concept depends on low level implementation F. Mallet SOLID 22

Copy: bad fix FileOutputStream output; boolean writeonconsole; SOLID DIP: Example void copy() throws IOException { for (int c = System.in.read(); c!= -1; c = System.in.read()) { if (writeonconsole) System.out.write(c); else output.write(c); } } High level concept depends on low level implementation F. Mallet SOLID 23

DIP: Example Copy: good fix OutputStream output; void copy() throws IOException { for (int c = System.in.read(); c!= -1; c = System.in.read()) { output.write(c); } } High level concept depends on an abstraction F. Mallet SOLID 24

Button and Lamp SOLID DIP: Another example Button ison: boolean + press() Lamp + turnon() + turnoff() F. Mallet SOLID 25

Button and Lamp SOLID DIP: Another example Button ison: boolean + press() Lamp + turnon() + turnoff() One fix Button «interface» ison: boolean ButtonListener Listener pattern + press() + turnon() + turnoff() Lamp + turnon() + turnoff() F. Mallet SOLID 26

Another abstraction SOLID DIP: Another example «abstract» PressSensitiveElement Listener pattern «interface» ActionListener + press() + actiondone() Button ispressed: boolean Lamp ison: boolean + actiondone() F. Mallet SOLID 27

Interface Segregation Principle Clients should not be forced to depend on methods that they do not use Symptom: Some clients use one group of member methods Other clients use another group Diagnostic: fat interfaces Cure Split the interface into several sub interfaces F. Mallet SOLID 28

TimedDoor: Code public class TimedDoor extends PlaybackListener implements ActionListener, Runnable { private boolean isopened = false; private Timer timer = new Timer(100, this); private AdvancedPlayer player; } void lock() { isopened = false; timer.stop(); } void unlock() { isopened = true; timer.setinitialdelay(5000); timer.setrepeats(false); timer.start(); } boolean isopen() { return isopened; } void timeout() { try { this.player = new AdvancedPlayer( ); player.setplaybacklistener(this); Thread playerthread = new Thread(this, "AudioPlayerThread"); playerthread.start(); } } public void actionperformed(actionevent arg0) { timeout(); } public void run() { try { player.play(); } catch (JavaLayerException e) { e.printstacktrace(); } } SOLID ISP: Example Timed Door: Interface PlayBackListener TimedDoor isopened: boolean + lock() + unlock() + isopened() # timeout() + actionperformed() + run() + run() «interface» Runnable + playbackstarted() + playbackfinished() «interface» ActionListener + actionperformed() F. Mallet SOLID 29