Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Brief introduction to Object Oriented Analysis and Design


Published on

This presentation was used to give a brief introduction to proper usage of Object Oriented Programming and to give a quick glance through Object Oriented Design principles

Published in: Software
  • Login to see the comments

  • Be the first to like this

Brief introduction to Object Oriented Analysis and Design

  1. 1. OOAD
  2. 2. Before we start… • Emphasis is more on Design rather than analysis • The definitions I’ll use will be informal, non- rigorous. • I won’t go in depths of design patterns. • My assumption is that you all know what is a class, object, inheritance and interface.
  3. 3. Why is it needed • Knowing rules of chess doesn’t make you Vishwanathan Anand • Similarly, knowing programming alone doesn’t make you a good Software Engineer • Learning “how to think in objects” is absolutely critical
  4. 4. Benefits • Comprehensibility (self-documenting) • Extensibility • Modifiability • Maintainability • Testability
  5. 5. Analysis & Design • Analysis emphasises the study and research of problem and requirements in order to gain deeper understanding of them • Design emphasises a “conceptual solution” that fulfils the requirements
  6. 6. OO Analysis & Design • OO Analysis: • Find and describe the objects/entities (and concepts) in a problem domain. • OO Design: • Define attributes and responsibilities of objects and how they collaborate with each other
  7. 7. Perspectives • Conceptual: • “What do you want to do?” • Implementation: • “How exactly will you do?”
  8. 8. Cohesion and Coupling • Cohesion: • How strongly related methods (or responsibilities) of that object are • Coupling: • How closely connected two objects are
  9. 9. OOP revisited A. Objects: 1. Data with Methods Things with Responsibilities 2. Entities: Representation of real world entities 3. Services: Model Concepts/Processes/sequence of actions 4. Value object: For eg. Money
  10. 10. OOP revisited… B. Inheritance and Polymorphism: 1. Special Case Family of similar objects 2. Inheritance + Polymorphism = Extensible, loosely coupled objects 3. Bad Use of Inheritance = Bad Coupling, Explosion of SubClasses
  11. 11. Bad use of Inheritance Example
  12. 12. Dealing with changing requirements: Suppose, we now want to control how Border of Rectangle looks
  13. 13. Dealing with changing requirements: Now we also want the ability to fill the Rectangle with a gradient. But what if now we also need control over border as well as ability to fill with gradient? “Code Duplication”!! Okay, now what if we need all these decorations on circle as well? Even more “Code Duplication”. Okay, now what if even more shapes come up and more kinds of decorations come up? Even more “Code Duplication”!!
  14. 14. Better use of Inheritance Favour aggregation over bad use of inheritance
  15. 15. OOP revisited… C. Polymorphism and (Type) Encapsulation: 1. Data Hiding Any kind of enclosing 2. Abstract Base Class: A class that never gets instantiated Representative/Placeholder for subclasses 3. Use ABC to encapsulate sub-classes from client, thereby reducing coupling
  16. 16. OOP revisited… D. Abstraction and (Implementation) Encapsulation: 1. Writing Abstract Base Class Expressing Responsibilities minus implementation 2. Think about object and it’s public interface (responsibilities) 3. Encapsulate the nuts and bolts in private methods
  17. 17. OOD principles 1. Information Expert: • Assign Responsibility to the object that has necessary information to carry it out 2. Pure Fabrication: • Assign Responsibility to a new Service object if Info Expert hurts cohesion / reuse potential
  18. 18. OOD principles… 3. High Cohesion: • Assign focussed, related responsibilities to an object 4. Low Coupling: • Avoid Bad coupling
  19. 19. Brief Intro to Design Patterns • A Pattern is problem-solution pair that is common, well known and has a name • Patterns are always guided by Principles • And you learn’t those principles in previous slides • Examples: Strategy —> Polymorphism, Type Encapsulation Facade —> Implementation Encapsulation
  20. 20. Further Reading • Applying UML and Patterns - Craig Larmann • Design Patterns Explained - Allan Shalloway • Domain Driven Design - Eric Evans (for backend developers)