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) <dependency> <groupId>org.eclipse.paho</groupId> <artifactId>org.eclipse.paho.client.mqttv3</artifactId> <version>1.2.5</version> </dependency> 10
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
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
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
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
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
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
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
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
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
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
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
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