Upgrade to Pro — share decks privately, control downloads, hide ads and more …

CSE360 Tutorial 04

CSE360 Tutorial 04

Introduction to Software Engineering
The SOLID Principles
(202206)

Javier Gonzalez-Sanchez
PRO

June 13, 2022
Tweet

More Decks by Javier Gonzalez-Sanchez

Other Decks in Programming

Transcript

  1. CSE 564
    Software Design
    Lecture:
    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. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 2
    Announcements
    • Monday, June 20

    View Slide

  3. Previously …
    Programming

    View Slide

  4. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 4
    Global Ideas
    • Create code Elegant and
    Efficient –Bjarne Stroustrup
    • Create code Simple and
    Direct –Grady Booch
    • Create code looks like
    written by someone who
    cares –Michael Feathers

    View Slide

  5. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 5
    Clean Code Principles
    • Readability
    Use Meaningful Names for Classes, Methods, and
    Variables
    Follow coding guidelines: e.g., read the Java Style
    Reference
    • KISS (Keep It Simple by K. Johnson) for your reader
    Small functions that do one thing
    • DRY (Do not Repeat Yourself):
    Avoid Code Bloat

    View Slide

  6. SOLID Principles
    Object-Oriented Design

    View Slide

  7. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 7
    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

  8. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 8
    Key Idea
    Design principles are not a perfume
    to be liberally scattered all over the
    system
    –Robert Martin

    View Slide

  9. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 9
    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

  10. Single Responsibility Principle
    SRP

    View Slide

  11. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 11
    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

  12. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 12
    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

  13. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 13
    SRP Example

    View Slide

  14. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 14
    SRP Example

    View Slide

  15. Open-Closed Principle
    OCP

    View Slide

  16. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 16
    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

  17. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 17
    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

  18. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 18
    OCP Example

    View Slide

  19. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 19
    OCP Example

    View Slide

  20. Liskov Substitution Principle
    LSP

    View Slide

  21. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 21
    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

  22. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 22
    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

  23. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 23
    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

  24. Interface Segregation Principle
    ISP

    View Slide

  25. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 25
    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

  26. Dependency Inversion Principle
    DIP

    View Slide

  27. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 27
    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

  28. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 28
    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

  29. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 29
    DIP Example

    View Slide

  30. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 30
    DIP Example
    What about ISP?

    View Slide

  31. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 31
    Reference
    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

  32. Javier Gonzalez-Sanchez | CSE360 | Fall 2020 | 32
    Assignment 02

    View Slide

  33. CSE 564 Software Design
    Javier Gonzalez-Sanchez, Ph.D.
    [email protected]
    Fall 2022
    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