Solid principles of oo design

  • 1,309 views
Uploaded on

The presentation discusses software design. It discusses the characteristics of a good and bad design. Then it talks about how to achieve a good design. Then finally we discuss the SOLID Principles of …

The presentation discusses software design. It discusses the characteristics of a good and bad design. Then it talks about how to achieve a good design. Then finally we discuss the SOLID Principles of Object Oriented Design. These are 5 principles compiled by Rober Cecil Martin aka Uncle Bob. The benefit of these principles is to achieve a good OO design which is high in cohesion and low in coupling thus easily adaptable to change

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,309
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
37
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Boutique product development company It is amazing what you can accomplish when you have a client-centric team to deliver outstanding products.
  • 2. SOLID Principles of OO Design Waleed Bin Dawood | Software Engineer Boutique product development company It is amazing what you can accomplish when you have a client-centric team to deliver outstanding products.
  • 3. "Any fool can write code that a computer can understand. Good programmers write code that humans can understand" Martin Fowler SOLID Principles of Object Oriented Design ● ● ● ● Software design What makes a design good or bad ? Design/Code Smells SOLID Principles Waleed Bin Dawood | Software Engineer
  • 4. SOLID Principles What is software design ? • • • • The source code is the design UML diagram represents part of a design Software design process includes coding, testing, refactoring… The programmer is the actual software designer. Waleed Bin Dawood | Software Engineer
  • 5. SOLID Principles Why do we need a good design ? • • • To deliver fast To manage change easily To deal with complexity Waleed Bin Dawood | Software Engineer
  • 6. SOLID Principles How to identify a bad design ? “In my BillG review meeting, the whole reporting hierarchy was there...and a person...whose whole job during the meeting was to keep an accurate count of how many times Bill said the F word. The lower the f***-count, the better.” -- Joel Spolsky, My First BillG Review But may be we need some better criteria :) Waleed Bin Dawood | Software Engineer
  • 7. SOLID Principles How to identify a bad design ? Design/Code Smells ● Rigidity - The design is hard to change ● Fragility - The design is easy to break ● Immobility - The design is hard to reuse ● Viscosity - It is hard to do the right thing Waleed Bin Dawood | Software Engineer
  • 8. SOLID Principles Good design What are the characteristics of a good design ? ● High Cohesion ● Low Coupling How to achieve a good design ? Follow programming practices of your language/framework Follow OO design principles Use design patterns • • • Waleed Bin Dawood | Software Engineer
  • 9. SOLID Principles Let’s go SOLID Initial Stands for (acronym) Concept S SRP Single responsibility principle a class should have only a single responsibility. O OCP Open/closed principle “software entities … should be open for extension, but closed for modification”. L LSP Liskov substitution principle “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”. I ISP Interface segregation principle “many client-specific interfaces are better than one general-purpose interface.” D DIP Dependency inversion principle one should “Depend upon Abstractions. Do not depend upon concretions.” Waleed Bin Dawood | Software Engineer
  • 10. SOLID Principles Single Responsibility Principle • • • • “There should never be more than one reason for a class to change.” -- Robert Martin, SRP paper Easier : A class should concentrate on doing one thing and one thing only It give you high cohesion It’s often hard to identify different responsibilities Waleed Bin Dawood | Software Engineer
  • 11. SOLID Principles Single Responsibility Principle • • Is SRP violated here ? Two responsibilities: o Connection management o Data Communication Waleed Bin Dawood | Software Engineer
  • 12. SOLID Principles Single Responsibility Principle • • Solution : Two responsibilities: o Connection management o Data Communication Waleed Bin Dawood | Software Engineer
  • 13. SOLID Principles Open/Closed Principle • • • “Software entities should be open for extension, but closed for modification.” -- Robert Martin paraphrasing Bertrand Meyer, OCP Paper Easier : you should be able to extend the behaviour of a module without changing it Abstraction is the key Waleed Bin Dawood | Software Engineer
  • 14. SOLID Principles Open/Closed Principle • Is OCP violated here ? Waleed Bin Dawood | Software Engineer
  • 15. SOLID Principles Open/Closed Principle • Solution: Waleed Bin Dawood | Software Engineer
  • 16. SOLID Principles Liskov Substitution Principle • • “Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.” -- Robert Martin, LSP Paper Easier : Subclasses should behave nicely when used in place of their parent class Waleed Bin Dawood | Software Engineer
  • 17. SOLID Principles Liskov Substitution Principle • • • • How would you model the relationship between a square and a rectangle ? Should the square class extends rectangle ? Many of you would say “yes” or “why not”. Square is a kind of Rectangle after all. An obvious IS-A relationship Issues in this Approach: o Square has unnecessary attribute ‘width’ o What happens when we want to calculate area ? o What happens if the client code is assuming height and width to be independent of each other Waleed Bin Dawood | Software Engineer
  • 18. SOLID Principles Dependency Inversion Principle • • “A. High level modules should not depend upon low level modules. Both should depend upon abstractions. B. Abstractions should not depend upon details. Details should depend upon abstractions.”-- Robert Martin, DIP paper Easier: o Use lot of interfaces (program to interface) o Use abstractions Waleed Bin Dawood | Software Engineer
  • 19. SOLID Principles Interface Segregation Principle • • “Clients should not be forced interfaces that they do not use.”-- Robert Martin, ISP paper Easier : avoid fat interfaces (cohesion) Waleed Bin Dawood | Software Engineer
  • 20. Human Computer Interaction Thank you for your time If you have any questions, please ask now or forever hold your peace Waleed Bin Dawood | Software Engineer
  • 21. Human Computer Interaction References • • • • • • • http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) http://www.slideshare.net/bbossola/geecon09-solid http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod http://www.slideshare.net/intellizhang/the-oo-design-principles http://www.slideshare.net/enbohm/solid-design-principles-9016117 http://www.oodesign.com/design-principles.html http://objectmentor.com/resources/publishedArticles.html Waleed Bin Dawood | Software Engineer