The Clean Code Alliance in Israel organized a special event about the SOLID Principles of Object-Oriented Design. I was glad to be invited to give a talk about “The SOLID Principles Illustrated by Design Patterns”. My friend Eyal Golan also gave a very nice talk about the Single Responsibility Principle.
Title: The SOLID Principles Illustrated by Design Patterns
Abstract: The goal of the SOLID design principles is to improve the Separation of Concerns, through weaker Coupling and stronger Cohesion. The main consequence should be software systems that are easier to maintain and to extend. However the definition of the SOLID principles is quite abstract, and some developers find it difficult to apply them in practice. In my talk I will show how well-known Design Patterns illustrate the application of the SOLID principles, and also show examples of how to follow these principles to Refactor and improve existing designs.
Bio: Hayim Makabee was born in Rio de Janeiro. He immigrated to Israel in 1992 and completed his M.Sc. studies on Computer Sciences at the Technion. Since then he worked for several hi-tech companies, including also some start-ups. Currently he is a Predictive Analytics Expert at Pontis. He is also a co-founder of the International Association of Software Architects (IASA) in Israel. Hayim is the author of a book about Object-Oriented Programming and has published papers in the fields of Software Engineering, Distributed Systems and Genetic Algorithms.
These are the original slides of Hayim’s presentation:
Here is the video of the talk (in Hebrew):
I would like to thank Boris Modylevsky and Itzik Saban for the organization of this event.
Feel free to share your comments below. Thanks!
Effective Software Design 
Pingback: SRP as part of SOLID | Learning and Improving as a Craftsman Developer
Thanks for sharing this excellent talk. On slide 24 it seems the dependency should now be “inverted” to the interface rather than the Singleton itself.
Cheers
Thanks for your comment, Roby. The method m1 still depends on the Singleton class S because it must call the getInstance() method of this class. The getInstance() method cannot be part of the interface because it is a static method that returns an instance of the concrete class S. In the next slide the class m1 must decide between calling the class S1 or S2. I’m sorry I don’t have a video in English explaining that. 🙂
Thanks Hayim, so in that case the D for Dependency Inversion is not fixed yet, since m1 still depends on the low level class – correct? (the slide marks V for D)
Right, in this example we reached Dependency Inversion in all other methods with the exception of m1. The reason is that the Singleton class S has actually a mix of two interfaces: a functional interface that was segregated as I and a “Factory interface” represented by the method getInstance(). The method m1 is the only one that depends on the “Factory interface”.