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

Announcement 2 No Lecture on Thursday

Do not forget to Submit your Homework 3

Next Step

To Do List (1 - 4) 5

To Do List ( 5 - 7) 6

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

To Do List (9) MQTT Version

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

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

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

No content

No content

To Do List (10) 14 Pull Request?

Questions 15

SOLID Do not forget the basics

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

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

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

Single Responsibility Principle SRP

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

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

SRP Example 23

SRP Example 24

Open-Closed Principle OCP

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

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

OCP Example 28

OCP Example 29

Liskov Substitution Principle LSP

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

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

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

Interface Segregation Principle ISP

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


 Dependency Inversion Principle DIP

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

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

DIP Example 39

Questions 40

CSC 509 Software Engineering Javier Gonzalez-Sanchez, Ph.D. javiergs@calpoly.edu 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.