Slide 1

Slide 1 text

Dr. Javier Gonzalez-Sanchez [email protected] www.javiergs.info o ffi ce: 14 -227 CSC 508/9 Software Engineering (Design & Deployment) Lecture 09. Software Product Line II

Slide 2

Slide 2 text

Announcement 2 No Lecture on Thursday

Slide 3

Slide 3 text

Do not forget to Submit your Homework 3

Slide 4

Slide 4 text

Next Step

Slide 5

Slide 5 text

To Do List (1 - 4) 5

Slide 6

Slide 6 text

To Do List ( 5 - 7) 6

Slide 7

Slide 7 text

To Do List (8) 7 trace() debug() info () warn () error() message 01 message 02 message 03 message 04 message 05 Logger Appender Appender

Slide 8

Slide 8 text

To Do List (9) MQTT Version

Slide 9

Slide 9 text

Pong 9 https://github.com/CSC3100/Pong-Game

Slide 10

Slide 10 text

Eclipse Paho for Java What is Eclipse Paho? • A set of MQTT client libr a ries developed by the Eclipse Found a tion. • It supports multiple l a ngu a ges, such a s J a v a , Python, J a v a Script, etc. Java Dependency (Maven) org.eclipse.paho org.eclipse.paho.client.mqttv3 1.2.5 10

Slide 11

Slide 11 text

Summary • MQTT: Lightweight, e ff i cient protocol for IoT and other use cases. • Mosquitto: A popular open-source MQTT broker. • Eclipse Paho: A versatile MQTT client library. • Java Example: https://github.com/CSC3100/MQTT 11

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

To Do List (10) 14 Pull Request?

Slide 15

Slide 15 text

Questions 15

Slide 16

Slide 16 text

SOLID Do not forget the basics

Slide 17

Slide 17 text

Key idea • Just like the source code a design should be cle a n, a nd th a t includes. • Keep it Simple - over-designing the system is a s b a d a s their a bsence when needed. • A design th a t is more th a n wh a t we need smells. • So, a bstr a ct cl a sses, interf a ces, design p a tterns, a nd other infr a structure elements th a t do not solve a problem cre a te a problem. • Elimin a ting design smells is the go a l of design principles. 17

Slide 18

Slide 18 text

Key Idea Design principles are not a perfume to be liberally scattered all over the system. Robert Martin (Agile m a nifesto, SOLID principles, Cle a n Code Book) 18

Slide 19

Slide 19 text

Design Principles There a re f ive 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) 19

Slide 20

Slide 20 text

Single Responsibility Principle SRP

Slide 21

Slide 21 text

Definition A cl a ss should h a ve only one responsibility SRP is a ll a bout underst a nding when and how to apply decoupling. Why? Bec a use e a ch responsibility implies a possibility of a ch a nge. 21

Slide 22

Slide 22 text

SRP Example • Im a gine th a t you need a piece of softw a re to read d a t a from diverse sensor devices ( a he a rt r a te monitor, a br a in-computer interf a ce, a skin conduct a nce sensor, etc.) • And you need to store th a t inform a tion for future use a lso. • For some sensors, we need to g a ther d a t a directly from a serial port. • For others, we use a WebSockets (third-p a rty APIs help us get d a t a from the physic a l device). • To store d a t a , we w a nt to be a ble to store d a t a in a local fi le (text f ile) or in a database 22

Slide 23

Slide 23 text

SRP Example 23

Slide 24

Slide 24 text

SRP Example 24

Slide 25

Slide 25 text

Open-Closed Principle OCP

Slide 26

Slide 26 text

De f inition Softw a re entities (functions, cl a sses, modules, etc.) should be open for extension but closed for modi f ic a tion. OCP is a ll a bout a chieving ch a nges a dding new code, not ch a nging the old code th a t a lre a dy 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 su ff er over time. OCP me a ns th a t we do not w a nt to modify the cl a ss, i.e., write code into a cl a ss. Once you cre a te a cl a ss a nd put th a t cl a ss in a production environment, you do not w a nt to touch th a t cl a ss. OCP c a n be s a tis f ied with a simple a nd e ff ective heuristic: inheritance 26

Slide 27

Slide 27 text

OCP Example • Im a gine you a re a sked to cre a te a progr a m to draw geometric shapes on screen. • We w a nt to dr a w circles a nd dr a w squares; m a ybe l a ter, we would a sk for dr a w triangles, etc. 27

Slide 28

Slide 28 text

OCP Example 28

Slide 29

Slide 29 text

OCP Example 29

Slide 30

Slide 30 text

Liskov Substitution Principle LSP

Slide 31

Slide 31 text

De f inition Subtypes must be substitut a ble for a ll their b a se types. i.e., a child should always be better than its parent. And, “better” me a ns more beh a viors, not less. Th a t principle is the a nswer proposed by Barbara Liskov (1988) to the questions: • Wh a t a re the ch a r a cteristics of the best inherit a nce hier a rchies? • Wh a t a re the tr a ps th a t could cre a te hier a rchies th a t jeop a rdize the OCP? 31

Slide 32

Slide 32 text

LSP Example • Im a gine you a lre a dy h a ve a cl a ss Circle, a nd you a re a sked to cre a te a cl a ss Cylinder. • Or m a ybe you h a ve a cl a ss Rectangle, a nd you a re a sked to cre a te a cl a ss Square ( a squ a re is a rect a ngle with the s a me width a nd height). • Or you h a ve a cl a ss LinkedList, a nd you a re a sked to cre a te a cl a ss PersistentLinkedList (one th a t writes out its elements to a stre a m a nd c a n re a d them b a ck l a ter). If you a re tempted to use inheritance from Circle to Cylinder, or from Rectangle to Square, or from LinkedList to PersistentLinkedList, i.e., cre a te a p a rent-child rel a tionship for a ny of these c a ses, you will have problems. 32

Slide 33

Slide 33 text

LSP Example • The cl a ss Cylinder would elimin a te the method c a lcul a teAre a () in Circle since c a lcul a ting a n a re a does not m a ke sense. It is impossible to use our Cylinder object to repl a ce a Circle object. • The cl a ss Square will m a ke the methods setWidth() a nd setHeight() to modify both width a nd height a ttributes (they a re equ a l in a squ a re, right?). Therefore, it will be impossible to use a Square object to repl a ce a Rectangle object. • The cl a ss PersistentLinkedList needs persistent (seri a liz a ble) objects while LinkedList does not. Moreover, prob a bly, PersistentLinkedList would need to throw some exceptions. 33

Slide 34

Slide 34 text

Interface Segregation Principle ISP

Slide 35

Slide 35 text

De f inition • Clients should not be forced to depend on methods th a t they do not use. • ISP de a ls with the dis a dv a nt a ge of “fat” interf a ces (or a bstr a ct cl a sses). • ISP recommends to broke up interfaces with a lot of methods into sever a l interf a ces. 35

Slide 36

Slide 36 text


 Dependency Inversion Principle DIP

Slide 37

Slide 37 text

De f inition • High-level modules should not depend on low-level modules. Both should depend on a bstr a ctions. • Tr a dition a l procedural programming cre a tes softw a re structures in which high-level modules depend on low-level modules. • The dependency structure of a well-designed object-oriented progr a m is “inverted” with respect to the dependency structure th a t gener a lly results from tr a dition a l procedur a l methods. • DIP is wh a t m a kes softw a re ful f ill the object-oriented p a r a digm. 37

Slide 38

Slide 38 text

De f inition • Hollywood Principle: “do not call us, we will call you.” • Review DIP whenever one cl a ss sends a message to a nother. DIP is a bout calling methods. • When doing th a t, depend on abstractions (use a bstr a ct cl a sses or interf a ces). 38

Slide 39

Slide 39 text

DIP Example 39

Slide 40

Slide 40 text

Questions 40

Slide 41

Slide 41 text

CSC 509 Software Engineering Javier Gonzalez-Sanchez, Ph.D. [email protected] Fall 2024 Copyright. These slides can only be used as study material for the class CSC509 at Cal Poly. They cannot be distributed or used for another purpose.