All Tools and no SOLID makes Jack/Jill a dull programmer

Learning and using tools are fantastic but to develop an optimal solution it's important that we implement these tools using best programming practices.

A tool is like the driver of a rally car and good programming practice is the co-driver providing the navigation. To win the race they both need to understand and support each other.

Transcript

1. All Tools and no SOLID makes Jack/Jill a dull programmer ASHESH BHARADWAJ
2. What do they all have in common?
3. They are all Tools  They address specific area of a problem  They keep evolving, sometimes drastically  Most of them have equally good alternatives  They are usually domain specific
4. PUBG Weapons Photo by dbltap.com
5. It takes more to be a PUBG star Photo by eurogamer.net
6. Programming Principles  The guiding force to optimize the implementation of the tools.  They are stable and universal.  Programming principles complement the tools
7. Mother of all programming principles
8. Change is inevitable  If there was to be only one version of an app  The principles and practices we follow is to prepare for the change  Change is welcome but it’s also a gateway for bugs to creep in  Minimize the impact by limiting the scope
9. SOLID Principles  SOLID programming principles for object oriented programming was introduced by Robert C. Martin in 2000  Single Responsibility Principle (SRP) Tom DeMarco, Meilir Page-Jones and others (1980s)  Open/Closed Principle (OCP) Bertrand Meyer (1988)  Liskov Substitution Principle (LSP) Barbara Liskov (1988)  Interface Segregation Principle (ISP) Robert C. Martin (1996)  Dependency Inversion Principle (DIP) Robert C. Martin (1996)
10. Single Responsibility Principle (SRP) A class should have only one reason to change
11. Open/Closed Principle (OCP) Classes should be open for extension but closed for modification
12. Liskov Substitution Principle (LSP) Subtypes must be substitutable for their base types
13. Interface Segregation Principle (ISP) Many client specific interfaces are better than one general purpose interface
14. Dependency Inversion Principle (DIP)  High-level modules should not depend on low-level modules. Both should depend on abstractions.  Abstractions should not depend upon details. Details should depend upon abstractions.
15. Where to go from here? Photo by Andrew Ridley on Unsplash
16. Q & A
17. That’s it! Thank You linkedin.com/in/asheshb twitter.com/asheshbt medium.com/@asheshb ASHESH BHARADWAJ