Single Responsibility Principle

Similar documents
Software Engineering

Software Design and SOLID Principles

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

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

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

Object Oriented Software Design - I

CSC207H: Software Design SOLID. CSC207 Winter 2018

17.11 Bean Rules persistent

Chapter 5 Object-Oriented Programming

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

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

OO Class Design Principles

Build Testable Client and Service Applications

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

TDDB84: Lecture 09. SOLID, Language design, Summary. fredag 11 oktober 13

Single Responsibility Principle (SRP)

Liskov Substitution Principle

Inheritance and object compatibility

Open Closed Principle (OCP)

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

Intro to: Design Principles

Conception Orientée Objets. Programmation SOLID

Lecture: Modular Design

SOLID: Principles of OOD

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

Influence of Design Patterns Application on Quality of IT Solutions

Object-oriented design principles

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

Bruno Bossola SOLID Design Principles

Object-Oriented Concepts and Design Principles

CMPS 115 Winter 04. Class #10 (2004/02/05) Changes/Review Programming Paradigms Principles of OOD <break> Design Patterns

Dependency Injection & Design Principles Recap Reid Holmes

Design Quality Assessment in Practice

Welcome to Design Patterns! For syllabus, course specifics, assignments, etc., please see Canvas

CSC207 Week 3. Larry Zhang

CS 520 Theory and Practice of Software Engineering Fall 2017

CS1150 Principles of Computer Science Objects and Classes

COURSE 2 DESIGN PATTERNS

Component-Level Design

Object-Oriented Design II

CS 320 Introduction to Software Engineering Spring March 06, 2017

Inheritance and Encapsulation. Amit Gupta

Object-Oriented Design

Basic design patterns

Software Engineering I (02161)

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

09. Component-Level Design

Inheritance. Inheritance Reserved word protected Reserved word super Overriding methods Class Hierarchies Reading for this lecture: L&L

Chapter 6: Inheritance

Principles of Object-Oriented Design

Introduction to Testing and Maintainable code

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

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

CS 520 Theory and Practice of Software Engineering Fall 2018

Software Paradigms (Lesson 3) Object-Oriented Paradigm (2)

Principles of OO Design

C++ Modern and Lucid C++ for Professional Programmers

Object-Oriented Design I - SOLID

Introduction Programming Using Python Lecture 8. Dr. Zhang COSC 1437 Fall 2017 Nov 30, 2017

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

Object- Oriented Design with UML and Java Part I: Fundamentals

Inheritance and Polymorphism

Object-Oriented Design I

Object-Oriented Design

Software Development

Maintainable Software. Software Engineering Andreas Zeller, Saarland University

CPSC 310: Sample Final Exam Study Questions 2014S1 (These are in addition to the Study Questions listed at the end of some lectures)

Course 2 October, 16, Adrian Iftene

Testing Object-Oriented Software. 22 November 2017

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

Abstract Class. Lecture 21. Based on Slides of Dr. Norazah Yusof

Abstraction. Design fundamentals in OO Systems. Fundamental Software Development Principles

6.170 Recitation #5: Subtypes and Inheritance

Java and OOP. Part 3 Extending classes. OOP in Java : W. Milner 2005 : Slide 1

ECE 122. Engineering Problem Solving with Java

Produced by. Agile Software Development. Eamonn de Leastar

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

Object-Oriented Design

Component-Level Design. Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman. For non-profit educational use only

Index. Dmitri Nesteruk 2018 D. Nesteruk, Design Patterns in Modern C++,

Princípy tvorby softvéru Dizajnové princípy

Chapter 8: Class and Method Design

Introduction to Object-Oriented Programming

Inheritance, and Polymorphism.

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

Design Patterns. CSC207 Winter 2017

Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page:

Cursul 6 27 Martie 2017

Design Patterns. CSC207 Fall 2017

Dependency Inversion, Dependency Injection and Inversion of Control. Dependency Inversion Principle by Robert Martin of Agile Fame

Object-Oriented Design II - GRASP

Applying Design Patterns to accelerate development of reusable, configurable and portable UVCs. Accellera Systems Initiative 1

5. Application Layer. Introduction

CAS 703 Software Design

Technical Metrics for OO Systems

Test Code Patterns. How to design your test code

Highlights of Previous Lecture

OOD Smells and Principles

Transcription:

Single Responsibility Principle Class should have only one responsibility which means class should be highly cohesive and implement strongly related logic. Class implementing feature 1 AND feature 2 AND feature 3 (and so on) violates SRP. class PlaceOrder def initialize(product) @product = product def run # 1. Logic related to verification of # stock availability # 2. Logic related to payment process # 3. Logic related to shipment process class PlaceOrder def initialize(product) @product = product def run StockAvailability.new(@product).run ProductPayment.new(@product).run ProductShipment.new(@product).run more than one contextually separated piece of code within single class large setup in tests (TDD is very useful when it comes to detecting SRP violation) separated classes responsible for given use case can be now reused in other parts of an application separated classes responsible for given use case can be now tested separately

Open/closed Principle Class should be open for extension and closed for modification. You should be able to ext class behavior without the need to modify its implementation (how? Don t modify existing code of class X but write a new piece of code that will be used by class X). class Logger def initialize(logging_form) @logging_form = logging_form puts message if @logging_form == console File.write( logs.txt, message) if @logging_form == file def initialize(logger: ConsoleLogger.new) @logger = logger class ConsoleLogger puts message if you notice class X directly references other class Y from within its code base, it s a sign that class Y should be passed to class X (either through constructor/single method) e.g. through depency injection complex if-else or switch statements class X functionality can be easily exted with new functionality encapsulated in a separate class without the need to change class X implementation (it s not aware of introduced changes) code is loosely coupled injected class Y can be easily mocked in tests class FileLogger File.write( logs.txt, message)

Liskov Substitution Principle Extension of open/closed principle stating that new derived classes exting the base class should not change the behavior of the base class (behavior of inherited methods). Provided that if a class Y is a subclass of class X any instance referencing class X should be able to reference class Y as well (derived types must be completely substitutable for their base types.). class Rectangle def initialize(width, height) @width, @height = width, height def set_width(width) @width = width def set_height(height) @height = height class Square < Rectangle # LSP violation: inherited class # overrides behavior of parent s methods def set_width(width) super(width) @height = height def set_height(height) super(height) @width = width if it looks like a duck, quacks like a duck but needs batteries for that purpose - it s probably a violation of LSP modification of inherited behavior in subclass exceptions raised in overridden inherited methods avoiding unexpected and incorrect results clear distinction between shared inherited interface and exted functionality

Interface Segregation Principle Client should not dep on interface/methods which it is not using. class Car def open def start_engine def change_engine # ISP violation: Driver instance does not make use # of #change_engine class Drive def take_a_ride(car) car.open car.start_engine # ISP violation: Mechanic instance does not make use # of #start_engine class Mechanic def repair(car) car.open car.change_engine one fat interface implemented by many classes where none of these classes implement 100% of interface s methods. Such fat interface should be split into smaller interfaces suitable for client needs. highly cohesive code avoiding coupling between all classes using a single fat interface (once a method in the single fat interface gets updated, all classes - no matter they use this method or not - are forced to update accordingly) clear separation of business logic by grouping responsibilities into separate interfaces

Depency Inversion Principle High-level modules (e.g. business logic) should not dep on low-level modules (e.g. database operations or I/O). Both should dep on abstractions. Abstractions should not dep on details. Details should dep on abstractions. def initialize # An instance of low-level class ConsoleLogger # is directly created inside high-level # EventTracker class which increases class # coupling @logger = ConsoleLogger.new def initialize(logger: ConsoleLogger.new) # Use depency injection as in closed/open...# principle. @logger = logger instantiation of low-level modules in high-level ones calls to class methods of low-level modules/classes increase reusability of higher-level modules by making them indepent of lower-level modules injected class can be easily mocked in tests