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.

Object Oriented Design - Good , Bad and Ugly

724 views

Published on

Object Orientation has become de-facto paradigm for building today's software systems. The Object Oriented Analysis and Design skill has become the essential arsenal with every successful designer. This course covers fundamentals of OO design aided with UML. The emphasis of the course is on creating sound design with OOA-D and UML is used as a communication tool.

Published in: Software, Technology, Business
  • Be the first to comment

Object Oriented Design - Good , Bad and Ugly

  1. 1. Object Oriented Design (OO-D) Good, Bad and Ugly Amod Kadam Cloud Manthan Software Solutions Pvt. Ltd. Sep 2012 V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 1
  2. 2. MODULE 2 – DESIGN Objective(s) • To understand the why and what of design V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 2 Topics • What and Why of Design ? • Design Characteristics • Design Process • Design Principles • Design Heuristics
  3. 3. What is DESIGN ? V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 3
  4. 4. What comes to mind ? V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 4
  5. 5. Design Perspective V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 5
  6. 6. What influences design ? V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 6
  7. 7. Defining Design V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 7
  8. 8. Some Design Definitions • “It’s where you stand with a foot in two worlds—the world of technology and the world of people and human purposes—and you try to bring the two together” - Creator of Lotus Notes - Mitch Kapor • Software design is a process of problem solving and planning for a software solution. After the purpose and specifications of software are determined, software developers will design or employ designers to develop a plan for a solution - Wikipedia V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 8
  9. 9. WHY DESIGN ? ‘Writing a clever piece of code that works is one thing ; designing something that can support a long lasting business is quite another’ V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 9
  10. 10. Purpose of Design • Solve problem • Satisfy need • Create mental model before building it • Communicate with stakeholders • Visualize Solution / Problem ! • Understand Complexity • Create better experience • Make Happy V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 10
  11. 11. Impact of Design • Results in long lasting system • Makes things work without problem • Tries to avoid potential problem during construction or after construction • Gives pleasure • Feel good • Promotions • Adverse Management Policy • Sad • Frustration • Loosing jobs V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 11
  12. 12. DESIGN CONCEPTS “Design is not the narrow application of formal skills, it is a way of thinking” - Chris Pullman V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 12
  13. 13. Context V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 13
  14. 14. Functionality V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 14
  15. 15. Easy to Use V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 15
  16. 16. Easy to Understand V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 16
  17. 17. Intuitive V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 17
  18. 18. Easy to maintain V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 18
  19. 19. What else ? • Feel Good • Easy to explain • … V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 19
  20. 20. SOFTWARE DESIGN CHARACTERISTICS V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 20
  21. 21. Rigidity • Tendency for software to be difficult to change, even in simple ways • Every change causes a cascade of subsequent changes in dependent modules • Don’t know, with any reliability, when the change will be finished • Manager fears to allow changes to software • Official rigidity sets in • Starts with design deficiency but leads to adverse management policy V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 21
  22. 22. Fragility • Tendency of the software to break in many places every time it is changed • Breakage occurs in areas that have no conceptual relationship with the area that was changed • Fills the hearts of managers with a feeling that something bad will happen • Every time managers authorize a fix, they fear that the software will break in some unexpected way • Impossible to maintain V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 22
  23. 23. Immobility • Inability to reuse software from other projects or from parts of the same project • Similar modules exists but with too much baggage • Work and risk required to separate the desirable parts of the software from the undesirable parts are too great to tolerate • Simply rewritten instead of reused V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 23
  24. 24. Viscosity… • Viscosity of the design – Comes about when changes sets in and there are more than one ways to make the change – Some of the ways preserve the design, others do not (i.e. they are hacks.) – Design preserving methods are harder to employ than the hacks, then the viscosity of the design is high – It is easy to do the wrong thing, but hard to do the right thing V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 24
  25. 25. … Viscosity • Viscosity of the environment – Comes about when the development environment is slow and inefficient – High Compile Time • Engineers will be tempted to make changes that don’t force large recompiles, even though those changes are not optimal from a design point of view – High Check in/Checkout • Hours to check in just a few files V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 25
  26. 26. Modularity • Separately named addressable components • Allows a program to be intellectually manageable • Easier to solve a complex problem when you break it into manageable pieces – Ease of development – Ease of planning – Software increments can be defined and delivered – Changes can be more easily accommodated – Testing and debugging can be conducted more effectively • Don’t over modularize – The simplicity of each small module will be overshadowed by the complexity of Integration V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 26
  27. 27. Functional Independence • Modules should have – single-minded function – aversion to excessive interaction with other modules • Promote reuse and/or repurpose • Easier to maintain and test • Cohesion – Qualitative Indication of Functional Independence • Coupling – Qualitative indication of the degree to which a module is connected to other modules and outside world V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 27
  28. 28. Cohesion • Degree to which the elements of a module belong together • Coincidental cohesion (ugly) – parts of a module are grouped arbitrarily (misc. classes) • Logical Cohesion – parts of a module are grouped because they logically are categorized to do the same thing, even if they are different by nature – e.g. grouping all mouse and keyboard input handling routines • Temporal Cohesion – parts of a module are grouped by when they are processed - the parts are processed at a particular time in program execution – E.g. catch an exception and close open files, creates an error log , notify user V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 28
  29. 29. …Cohesion • Procedural Cohesion – parts of a module are grouped because they always follow a certain sequence of execution – (e.g. a function which checks file permissions and then opens the file) • Sequential Cohesion – parts of a module are grouped because the output from one part is the input to another part like an assembly line – e.g. a function which reads data from a file and processes the data • Functional Cohesion (Good) – Parts of a module are grouped because they all contribute to a single well- defined task of the module – e.g. tokenizing a string of XML V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 29
  30. 30. Consequences of Low Cohesion • Increased difficulty in understanding modules • Increased difficulty in maintaining a system, because logical changes in the domain affect multiple modules, and because changes in one module require changes in related modules • Increased difficulty in reusing a module because most applications won’t need the random set of operations provided by a module V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 30
  31. 31. Coupling… • In computing and systems design a loosely coupled system is one in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components - Wikipedia • In software engineering, coupling or dependency is the degree to which each program module relies on each one of the other modules. - Wikipedia • Software modules, objects will always have some form of coupling V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 31
  32. 32. …Coupling… • Content Coupling – one module modifies or relies on the internal workings of another module (e.g., accessing local data of another module) • Global Coupling (common coupling) – Sharing same global data • External Coupling – Sharing externally imposed data format , communication protocol • Control Coupling – Control coupling is one module controlling the flow of another, by passing it information on what to do (e.g., passing a what-to-do flag) V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 32
  33. 33. Coupling… • Data Structured Coupling (stamp) – Share a composite data structure and use only a part of it, possibly a different part • Data Coupling – share data through, for example, parameters • Message Coupling – message passing • No Coupling – Modules do not communicate at all with one another V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 33
  34. 34. …Coupling V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 34 - Wikipedia Implications of Tight Coupling •One module usually forces a ripple effect of changes in other modules •Assembly of modules might require more effort and/or time due to the increased inter-module dependency •A particular module might be harder to reuse and/or test because dependent modules must be included
  35. 35. DESIGN PROCESS V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 35
  36. 36. Design Process • Incremental • Iterative • Focus on essential aspects • Intellectual • Creative • Rational • Early designs never an exact match of shipped version • Sloppy Process • Nondeterministic V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 36
  37. 37. Sloppy Process • Finished design looks well-organized ,clean but Process is Sloppy • Process is Myopic – Take False Steps and go down blind alleys • Making mistakes is the point of design • Design corrections are simpler than correcting after full blown code • Hard to know when design is good enough ? – Good Solution is subtly different than a poor one • How much details is enough ? • How do you know - When are you done ? V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 37
  38. 38. Nondeterministic • Same problem is solved differently by each person • Person Dependent ? • No. of ways to solve problem • Which one is correct ? V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 38
  39. 39. All about Tradeoffs • Choosing one over another • Is Fast Response Rate is a more important or minimizing development time ? • Is Scale critical or performance ? • Is it configurability or performance ? • Should be easy to use or development time critical ? • …. V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 39
  40. 40. Heuristic Process • Rules of Thumb • Things to try which works in most of the cases • Involves trial and error • Not a repeatable process • No guarantee that you will produce the exact same software design elements V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 40
  41. 41. Controlling Possibilities • Design should create possibilities – Legal possibilities – Consistent mechanism – way of doing • Design should Partly restrict possibilities – Bring discipline – Prevent ad-hoc way of doing the things – E.g. Constructing object in no. of ways - problematic V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 41
  42. 42. Refinement • Process of elaboration • Part of top-down design strategy • Helps designer to specify the low-level details as design progresses V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 42
  43. 43. How to Create Good Design ? • Design Principles – Guiding philosophy • Design Heuristics – Rules of Thumb • Refactoring – Process of improving internal structure of code without modifying its functionality V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 43
  44. 44. DESIGN PRINCIPLES V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 44
  45. 45. Principles , Patterns & Practices V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 45 Principles Practices Establish overriding philosophy for guiding designer Design Representations (UML) Software Design Guides in building Heuristics Patterns
  46. 46. Software Engineering Principles • The Reason It All Exists - To provide value to its users • Keep it Simple , Stupid ! (KISS) • Maintain the Vision - Avoids ‘two [or more] minds’ about itself • What You Produce, Others Will Consume • Be Open to the Future • Plan ahead for reuse V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 46
  47. 47. Design Modeling Principles • Design should be traceable to the analysis model • Design in the context of Architecture • Design of data is as important as design of processing functions • Interfaces must be designed with care • User Interface design should be tuned to the needs of an end user • Component-level design should be functionally independent • Components should be loosely coupled to one another and to the external environment • Design representations should be easily understandable • Strive for design simplicity with each iteration V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 47
  48. 48. SOFTWARE DESIGN HEURISTICS V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 48
  49. 49. Definition : Heuristics • Heuristic ( Greek: "find" or "discover") refers to experience-based techniques for problem solving, learning, and discovery • Where an exhaustive search is impractical, heuristic methods are used to speed up the process of finding a satisfactory solution • Examples : a rule of thumb, an educated guess, an intuitive judgment, or common sense V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 49
  50. 50. Where do we stand • Day 1 – Module 1 – Setting the Context – Module 2 – Design – Module 3 – Object Oriented (OO) Paradigm • Day 2 – Module 4 – OO Principles – Module 5 – Design Patterns – Module 6 – Creational Patterns V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 50
  51. 51. Cloud Manthan Software Solutions Pvt. Ltd. http://www.cloudmanthan.com V 1.0 www.cloudmanthan.com 51 Cloud Manthan Software Solutions Private Limited E-3,Lokmanya Pan Bazar,Opp. Everard Nagar Chunabhatti (E) , Eastern Express Highway, Sion Mumbai - 400 022 amod.kadam@cloudmanthan.com +91 98923 00901

×