Session 33 More on SOLID Steve Chenoweth Office: Moench Room F220 Phone: (812) 877-8974 Chandan Rupakheti Office: Moench.

Slides:



Advertisements
Similar presentations
Design Principles & Patterns
Advertisements

Since 1995, we’ve been building innovative custom solutions specifically designed to meet the unique needs of America’s most recognized companies. If you.
St Louis Day of.NET 2011 Refactoring to a SOLID Foundation Steve Bohlen Senior Software Engineer SpringSource/VMware Blog:
General OO Concepts and Principles CSE301 University of Sunderland Harry R. Erwin, PhD.
Lecture 9 Improving Software Design CSC301-Winter 2011 – University of Toronto – Department of Computer Science Hesam C. Esfahani
SOLID Object Oriented Design Craig Berntson
CSSE 374: Introduction to Object- Oriented Analysis and Design Q1 Steve Chenoweth Office: Moench Room F220 Phone: (812)
1 Software Maintenance and Evolution CSSE 575: Session 6, Part 1 The “SEAM” Model Steve Chenoweth Office Phone: (812) Cell: (937)
CSSE 374: More GRASP’ing and Use Case Realization Steve Chenoweth Office: Moench Room F220 Phone: (812) These.
CSSE 374: Design Class Diagrams Steve Chenoweth Office: Moench Room F220 Phone: (812) These slides and others.
CLASS DESIGN PRINCIPLES Lecture 2. The quality of the architecture What is a good design? It is the design that at least does not have signs of “bad”.
CSSE 374: More Object Design with Gang of Four Design Patterns Steve Chenoweth Office: Moench Room F220 Phone: (812)
1 OO Design Novosoft, 2001 by V. Mukhortov. 2 OO Design Goals  Flexibility Changes must be localized  Maintainability Modules requiring changes can.
Chandan Rupakheti Office: Moench Room F203 Phone: (812) These slides and others derived from Shawn Bohner, Curt.
Company Confidential – Do Not Duplicate 2 Copyright 2008 McLane Advanced Technologies, LLC S.O.L.I.D. Software Development Achieving Object Oriented Principles,
Software Engineering. Administrivia This is me: Cyndi Rader You can reach me: Or find me here: BB 280D Class notes here:
© 2004 Capgemini - All rights reserved SOLID - OO DESIGN PRINCIPLES Andreas Enbohm, Capgemini.
CSE 301 Exam Revision Lecture
Introduction to SOLID Principles. Background Dependency Inversion Principle Single Responsibility Principle Open/Closed Principle Liskov Substitution.
CSSE 374: More GRASP’ing for Object Responsibilities
S.O.L.I.D. Software Development 12 January 2010 (Martin Verboon, Patrick Kalkman, Stan Verdiesen)
Башкирцев (Старовер) Станислав JavaTalks OOD Principles.
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 12-5 Software Engineering Design Goals.
Coupling Cohesion Chandan R. Rupakheti Steve Chenoweth (Chapter 18)
Design Principles iwongu at gmail dot com.
The benefits of SOLID in software development Ruben Agudo Santos (GS-AIS-HR)
 What is SOLID  The S in SOLID  The O in SOLID  The L in SOLID  The I in SOLID  The D in SOLID  Questions.
Software Design Principles
Incremental Design Why incremental design? Goal of incremental design Tools for incremental design  UML diagrams  Design principles  Design patterns.
Elements of OO Abstraction Encapsulation Modularity Hierarchy: Inheritance & Aggregation 4 major/essential elements3 minor/helpful elements Typing Concurrency.
Single Responsibility Principle Steve Chenoweth Office: Moench Room F220 Phone: (812) Chandan Rupakheti Office:
Software Design Patterns Curtsy: Fahad Hassan (TxLabs)
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 11a: Component-Level Design Software Engineering: A Practitioner’s Approach, 6/e Chapter.
Design for testability as a way to good coding Simone Chiaretta Architect, Council of the EU December 9 th,
High Cohesion Low Coupling Old Standards for Object Oriented Programming.
Five design principles
CHAPTER 3 MODELING COMPONENT-LEVEL DESIGN.
Principles of Object Oriented Design
PRINCIPLES OF OBJECT ORIENTED DESIGN S.O.L.I.D. S.O.L.I.D Principles What is SOLID?  Acrostic of 5 Principles:  The Single Responsibility Principle.
Component Design Elaborating the Design Model. Component Design Translation of the architectural design into a detailed (class-based or module- based)
SOLID Design Principles
Dependency Inversion Principle Jon McBee Principal Software Engineer Ultratech CNT.
F-1 © 2007 T. Horton CS 4240 Principles of SW Design More design principles LSP, OCP, DIP, … And another pattern Decorator.
Dependency Inversion By Steve Faurie. Dependency Inversion Described in Agile Principles, Patterns and Practices in C# by Robert C. Martin.
SOLID PHP & Code Smell Wrap-Up
Liskov Substitution Principle Jon McBee CLA, CLED, CTD, CPI, LabVIEW Champion.
Microsoft Advertising 16:9 Template Light Use the slides below to start the design of your presentation. Additional slides layouts (title slides, tile.
Beginning Software Craftsmanship Brendan Enrick Steve Smith
14 Jul 2005CSE403, Summer'05, Lecture 09 Lecture 09: Fundamental Principles and Best Practices for Software Design Valentin Razmov.
Mantas Radzevičius ifm-2/2
Interface Segregation / Dependency Inversion
Course information Old exam Resit Report Result and walkthrough
Dependency Inversion Principle
Software Design Principles
Software Architecture & Difference from Design
Copyright © by Curt Hill
Software Engineering: A Practitioner’s Approach, 6/e Chapter 11 Component-Level Design copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Tech·Ed North America /18/ :26 AM
Software Design Principles
lecture 08, OO Design Principle
11/29/2018 © 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks.
15 letters that will change your code
The SOLID Principles.
A (partial) blueprint for dealing with change
European conference.
Object Oriented Design & Analysis
Dependency Inversion principle
Some principles for object oriented design
Liskov Substitution Principle (LSP)
Chapter 10 – Component-Level Design
Presentation transcript:

Session 33 More on SOLID Steve Chenoweth Office: Moench Room F220 Phone: (812) Chandan Rupakheti Office: Moench Room F203 Phone: (812)

Today The SOLID coding exercises See course website for zip file of all 5 of these They go with the quiz to turn in before class (as usual) Bring along your answers to discuss in class, too 2

Recall what SOLID is: S - SRP: Single Responsibility Principle We discussed this one in Session 13 O - OCP: Open Closed Principle L - LSP: Liskov Substitution Principle I - ISP: Interface Segregation Principle D - DIP: Dependency Inversion Principle Pioneered by Robert Martin (Uncle Bob) 3

Recall SRP THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE. (You looked at Pablo’s eBook on this – see especially pp ) 4

OCP SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION BUT CLOSED FOR MODIFICATION. 5

LSP FUNCTIONS THAT USE REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT. 6

ISP CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE. 7

DIP A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS. B. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS 8

More Info Look at the SOLID article we saw before. There’s more in there beyond SRP! The SRP part you already studied is thru p 26. Then there’s an article on each of the other SOLID principles, too. 9

Let’s Learn By Doing! 10 Download SolidExamples (a zip file of 5 Java examples) from the course website. The quiz asks describe where there are issues, with which of the SOLID principles. And – How you would fix them! Do the quiz before class, as usual, but also be ready to discuss your answers in class.

A “Solid” Summary SRP: THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE. OCP: SOFTWARE ENTITIES SHOULD BE OPEN FOR EXTENSION BUT CLOSED FOR MODIFICATION LSP: FUNCTIONS THAT USE REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT. ISP: CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE. DIP: HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS 11