$30 off During Our Annual Pro Sale. View Details »

CSE564 Lecture 08

CSE564 Lecture 08

Software Design
The SOLID Design Principles
(202102)

Javier Gonzalez-Sanchez
PRO

September 08, 2020
Tweet

More Decks by Javier Gonzalez-Sanchez

Other Decks in Programming

Transcript

  1. jgs
    CSE 564
    Software Design
    Lecture 08: The SOLID Design Principles
    Dr. Javier Gonzalez-Sanchez
    [email protected]
    javiergs.engineering.asu.edu | javiergs.com
    PERALTA 230U
    Office Hours: By appointment

    View Slide

  2. jgs
    564 00001000
    Quiz 03
    § Open Today and it is Due by September 21, 6:00 PM (AZ time).
    The quiz will not be extended
    Most questions about Lecture 2, 3, 4 and 6 (Papers 1 to 4)

    View Slide

  3. jgs
    SOLID Principles
    Object-Oriented Design

    View Slide

  4. jgs
    564 00001000
    Key idea
    § Just as the source code a design should be clean and that include
    Keep it Simple
    A design that is more than what we need smells
    So, abstract classes, interfaces, design patterns, and other infrastructure
    elements that do not solve a problem and are there to over-design the
    system are as bad as their absence when needed.
    Eliminate design smells is the goal of design principles.

    View Slide

  5. jgs
    564 00001000
    Key Idea
    Design principles are not a perfume
    to be liberally scattered all over the system
    –Robert Martin

    View Slide

  6. jgs
    564 00001000
    Design Principles
    There are five key design principles to consider in Object-Oriented:
    § Single Responsibility Principle (SRP)
    § Open-Closed Principle (OCP)
    § Liskov Substitution Principle (LSP)
    § Interface Segregation Principle (ISP)
    § Dependency Inversion Principle (DIP)

    View Slide

  7. jgs
    Single Responsibility Principle
    SRP

    View Slide

  8. jgs
    564 00001000
    Definition
    A class should have only one responsibility
    SRP is all about understanding when and how to apply decoupling.
    Why?
    Because each responsibility implies a possibility of a change.

    View Slide

  9. jgs
    564 00001000
    SRP Example
    § Imagine that you need a piece of software to read data from diverse sensor
    devices (a heart rate monitor, a brain-computer interface, a skin
    conductance sensor, etc.)
    § And you need to store that information for future use also.
    § For some sensors, we need to gather data directly from a serial port.
    § For others, we use a WebSockets (third-party APIs help us get data from
    the physical device).
    § To store data, we want to be able to store data in a local file (text file) or in a
    database

    View Slide

  10. jgs
    564 00001000
    SRP Example

    View Slide

  11. jgs
    564 00001000
    SRP Example

    View Slide

  12. jgs
    Open-Closed Principle
    OCP

    View Slide

  13. jgs
    564 00001000
    Definition
    Software entities (functions, classes, modules, etc.) should be open for
    extension but closed for modification.
    OCP is all about achieving changes adding new code, not changing the old
    code that already works.
    Closure cannot be complete. There will always be some change against
    which the entity is not closed. Thus, the closure must be strategic. As a
    developer, make educated guesses about the likely kinds of changes that the
    application could suffer over time.
    OCP means that we do not want to modify the class, i.e., write code into a
    class. Once you create a class and put that class in a production
    environment, you do not want to touch that class.
    OCP can be satisfied with a simple and effective heuristic: inheritance

    View Slide

  14. jgs
    564 00001000
    OCP Example
    § Imagine you are asked to create a program to draw geometric shapes on
    screen.
    § We want to draw circles and draw squares; maybe later, we would ask for
    draw triangles, etc.

    View Slide

  15. jgs
    564 00001000
    OCP Example

    View Slide

  16. jgs
    564 00001000
    OCP Example

    View Slide

  17. jgs
    Liskov Substitution Principle
    LSP

    View Slide

  18. jgs
    564 00001000
    Definition
    Subtypes must be substitutable for all their base types.
    i.e., a child should always be better than its parent. And, “better” means
    more behaviors, not less.
    That principle is the answer proposed by Barbara Liskov (1988) to the
    questions:
    § What are the characteristics of the best inheritance hierarchies?
    § What are the traps that could create hierarchies that jeopardize the OCP?

    View Slide

  19. jgs
    564 00001000
    LSP Example
    § Imagine you already have a class Circle, and you are asked to create a
    class Cylinder.
    § Or maybe you have a class Rectangle, and you are asked to create a
    class Square (a square is a rectangle with the same width and height).
    § Or you have a class LinkedList, and you are asked to create a
    class PersistentLinkedList (one that writes out its elements to a stream
    and can read them back later).
    If you are tempted to use inheritance from Circle to Cylinder, or
    from Rectangle to Square, or from LinkedList to PersistentLinkedList, i.e.,
    create a parent-child relationship for any of these cases, you will have
    problems.

    View Slide

  20. jgs
    564 00001000
    LSP Example
    § The class Cylinder would eliminate the
    method calculateArea() in Circle since calculating an area does not make
    sense. It is impossible to use our Cylinder object to replace a Circle object.
    § The class Square will make the methods setWidth() and setHeight() to
    modify both width and height attributes (they are equal in a square, right?).
    Therefore, it will be impossible to use a Square object to replace
    a Rectangle object.
    § The class PersistentLinkedList needs persistent (serializable) objects
    while LinkedList does not. Moreover,
    probably, PersistentLinkedList would need to throw some exceptions.

    View Slide

  21. jgs
    Interface Segregation Principle
    ISP

    View Slide

  22. jgs
    564 00001000
    Definition
    § Clients should not be forced to depend on methods that they do not use.
    § ISP deals with the disadvantage of “fat” interfaces (or abstract classes).
    § ISP recommends to broke up interfaces with a lot of methods into several
    interfaces.

    View Slide

  23. jgs
    Dependency Inversion Principle
    DIP

    View Slide

  24. jgs
    564 00001000
    Definition
    § High-level modules should not depend on low-level modules. Both should
    depend on abstractions.
    § Traditional procedural programming creates software structures in which
    high-level modules depend on low-level modules.
    § The dependency structure of a well-designed object-oriented program
    is “inverted” with respect to the dependency structure that generally results
    from traditional procedural methods.
    § DIP is what makes software fulfill the object-oriented paradigm.

    View Slide

  25. jgs
    564 00001000
    Definition
    § Hollywood Principle: “do not call us, we will call you.”
    § Review DIP whenever one class sends a message to another. DIP is about
    calling methods.
    § When doing that, depend on abstractions (use abstract classes or
    interfaces).

    View Slide

  26. jgs
    564 00001000
    DIP Example

    View Slide

  27. jgs
    564 00001000
    DIP Example
    What about ISP?

    View Slide

  28. jgs
    564 00001000
    Homework
    Read:
    § Design Patterns: Abstraction and Reuse of Object-Oriented Design
    Gamma, Helm, Johnson, Vlissides
    § European Conference on Object-Oriented Programming
    October 1993
    § This will become:

    View Slide

  29. jgs
    564 00001000
    Questions about your Assignment 02

    View Slide

  30. jgs
    CSE 564 Software Design
    Javier Gonzalez-Sanchez, Ph.D.
    [email protected]
    Fall 2021
    Copyright. These slides can only be used as study material for the class CSE564 at ASU.
    They cannot be distributed or used for another purpose.

    View Slide