Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OOPS basics and SOLID Principles

OOPS basics and SOLID Principles

This presentation contains some basics of object oriented programming and covers SOLID design principles with an example.

Kaushal Dhruw

May 26, 2018
Tweet

More Decks by Kaushal Dhruw

Other Decks in Programming

Transcript

  1. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved.

    C2M – App Architecture Model-View-Presenter (MVP) Model-View-ViewModel (MVVM) - Dinkar Kumar - Suyash Gupta - Kaushal Dhruw
  2. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 2 Guidelines • Cell phones in silent mode • No ungentlemanly conduct please – No abuse of Wi-Fi or other resources – Respect fellow members • Suggestions are welcome • It is an open session, ask your questions anytime, unless specified otherwise.
  3. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 3 Pune Mobile Developers • Started in August 2013. Part of Google Developer Communities since Jan 2017. • “Increase awareness of fast growing mobile technology among Developers” • Currently has 4800+ members • 37 meetups so far
  4. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 4 Announcements • Volunteers • Collaborative projects 4
  5. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 5 C2M meetup series • Cover all the phases of app development. • Learn the 2 dominating players in the market. • Create same app on Android and iOS (in parts). • Take your first step towards becoming complete mobile developer. • Learn from the community. 5
  6. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 6 Introduction • Why architect mobile apps? – The Basics – Why not put everything in activity / view controller? – SOLID Principles – Real world use case • MVC vs MVP vs MVVM
  7. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 7 The Basics • This is essential for all patterns, OOPS and principles. • Consider this:
  8. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 8 The Basics • D d = new D() ? • C c = new C() ? • A a = new A(){…} – anonymous? • B b = new B() ? • B b = new B() {…} - anonymous? • True • True • True • False • True
  9. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 9 The Basics • D d = new C() ? • C c = new D() ? • X x = new C(), x = new D()? • A a = new D(), C c = a? • B b = new C(), X x = b? • False • True • True • False • True
  10. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 10 Summary • D d = new D() ? • C c = new C() ? • A a = new A(){…} – anonymous? • B b = new B() ? • B b = new B() {…} - anonymous? • D d = new C() ? • C c = new D() ? • X x = new C(), x = new D()? • A a = new D(), C c = a? • B b = new C(), X x = b?
  11. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 11 Introduction • Why architect mobile apps? – The Basics – Why not put everything in activity / view controller? – SOLID Principles – Real world use case • MVC vs MVP vs MVVM
  12. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 12 I will do it my way One activity / view controller will do everything The cleanest code ever 1 2
  13. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 13 What is this code doing here? Did I really write this? After some time
  14. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 14 Put everything in one class?? Do not put everything in one class, it makes the code: • Spaghetti • Tightly coupled • Hard to read, maintain and unit test • Error prone • Difficult to debug
  15. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 15 SOLID Principles 5 design principles intended to make software designs more understandable, flexible and maintainable • S – Single Responsibility Principle • O – Open / Closed Principle • L – Liskov Substitution Principle • I – Interface Segregation Principle • D – Dependency Inversion Principle
  16. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 16 Logger use case Consider a logger class. It logs user events locally and syncs the logs to the server based on certain conditions. For this purpose, I created a class that: – Reads local logs – Establishes connection and pushes logs to remote server – Clears local logs
  17. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 17 LogSync.java Too many responsibilities
  18. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 18 Single Responsibility Principle A class should have one and only one responsibility According to this definition the Log sync class should be divided into 3 separate classes: • LogHandler – for reading and erasing local logs • NetworkHandler – for communicating with remote • LogSync – for updating remote server with logs
  19. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 19 Classes with single responsibility
  20. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 20 Open / Closed Principle Classes should be open for extension but closed for modification If I want to add say userId, with every log statement, I should be able to do it simply by extending LogHandler. The method logsFromLocal() is final. This way we are making sure our code is intact, but can still be extended as needed.
  21. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 21 Interface segregation principle Several specific interfaces are better than one generic interface Clients should not be forced to override methods that are of no use to the client. This is the only principle for interface in SOLID. Consider the LogListener interface of LogSync. This can be broken down into 2 interfaces
  22. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 22 Interface segregation principle Now background sync need not implement onProgressUpdate(…). As it is useless to monitor log upload progress for background log sync. However if there is an option in UI, then LogUploadListener can be used.
  23. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 23 Dependency inversion principle Classes should depend on abstractions not implementations This encourages loose coupling and makes code maintainable and testable. Depends on LogHandler Class not abstraction Depends on NetworkHandler Class not abstraction
  24. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 24 Dependency inversion principle
  25. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 25 Dependency inversion principle Depends on abstraction
  26. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 26 Liskov substitution principle Derived types must be completely substitutable for their base types In our LogSync example. After following the 4 SOLID principles, we now depend on abstractions of LogHandler and NetworkHandler. According to LSP, we should be able to substitute LogHandlerImpl or NetworkHandlerImpl with their siblings, or classes that implement the relevant interfaces, without affecting the flow of the program or making any unnecessary changes.
  27. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 27 Liskov substitution principle
  28. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 28 SOLID Principles 5 design principles intended to make software designs more understandable, flexible and maintainable • S – Single Responsibility Principle • O – Open / Closed Principle • L – Liskov Substitution Principle • I – Interface Segregation Principle • D – Dependency Inversion Principle
  29. Copyright © 2016 Talentica Software (I) Pvt Ltd. All rights

    reserved. Copyright ©2016 Talentica Software (I) Pvt Ltd. All rights reserved. 29 MVC vs MVP vs MVVM • This series is for beginners too. • MVP is a direct derivative of MVC and extremely popular for android development • Apple’s MVC is sometimes referred as Massive-View- Controller. It is too common and several examples are available. So we chose MVVM • Let’s see MVP and MVVM in action 29