Oops Concepts


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Oops Concepts

    1. 1. Object Oriented Concepts An overview and refresher for technology professionals
    2. 2. Goals <ul><li>Give you talking points so you may: </li></ul><ul><ul><li>Continue this discussion at your own organizations </li></ul></ul><ul><ul><li>Debate how I organized things and come up with a “better” way </li></ul></ul><ul><li>This is just a starting point! </li></ul>
    3. 3. Agenda <ul><li>Perspectives </li></ul><ul><li>Objects and approaches </li></ul><ul><li>Object Oriented concepts </li></ul><ul><ul><li>Encapsulation </li></ul></ul><ul><ul><li>Abstraction </li></ul></ul><ul><ul><li>Inheritance </li></ul></ul><ul><ul><li>Polymorphism </li></ul></ul><ul><li>Surprises! </li></ul>
    4. 4. A non-techie person! <ul><li>For analysts… </li></ul><ul><ul><li>Understanding OO Concepts can give you a “common language” to better communicate with your alien developers </li></ul></ul><ul><li>For managers … </li></ul><ul><ul><li>Planning at the object level allow for faster development (no more waterfall) </li></ul></ul><ul><ul><li>Reduced risks (big scary things are history--- now you get lots of little scary things, more milestones, faster and more frequent deliverables, etc.) </li></ul></ul>
    5. 5. Perspectives
    6. 6. Perspective <ul><li>All data processing involves: </li></ul><ul><ul><li>Input </li></ul></ul><ul><ul><li>Processing </li></ul></ul><ul><ul><li>Output </li></ul></ul><ul><li>Nothing more, nothing less </li></ul><ul><li>That’s why its called DATA processing and INFORMATION technology </li></ul>
    7. 7. Another perspective… <ul><li>“ Divide and conquer” </li></ul><ul><li>Put another (more applicable) way… </li></ul><ul><ul><li>Divide larger problems into smaller problems so they are more manageable </li></ul></ul>
    8. 8. Why divide? Too much information! Too complicated for a Thursday evening!
    9. 9. Sounds simple enough… <ul><li>Input, output, processing--- check! </li></ul><ul><li>Divide and conquer--- check! </li></ul><ul><li>No big scary database diagrams--- check! </li></ul><ul><li>Then why is analysis for software development projects so hard? </li></ul>
    10. 10. Sounds simple … <ul><ul><li>The business has needs </li></ul></ul><ul><ul><ul><li>“ We need specific implementation and a stable deliverable from this project in 2 weeks.” </li></ul></ul></ul><ul><ul><li>The techies have needs </li></ul></ul><ul><ul><ul><li>“ on what object model?!” </li></ul></ul></ul><ul><ul><li>…and these needs often conflict with one another </li></ul></ul>
    11. 11. Sounds simple … <ul><li>Conflict with one another? </li></ul><ul><ul><li>The business wants and needs software so it can compete, grow, and profit </li></ul></ul><ul><ul><ul><li>Side note: profit is good . Without profit there is no business, no job, no conversation </li></ul></ul></ul><ul><ul><li>The technical folks want: </li></ul></ul><ul><ul><ul><li>To create software that fills a need </li></ul></ul></ul><ul><ul><ul><li>Use technology and techniques that make it easy/possible to be built </li></ul></ul></ul><ul><ul><ul><li>Not make a program that is a nightmare to maintain </li></ul></ul></ul>
    12. 12. Why are we here? <ul><li>The business and the technical folks want the same thing but use different words </li></ul><ul><li>By learning a “common language” and a “common thought process” the business and technical teams will be more productive and a lot less stressed </li></ul>
    13. 13. Objects and Approaches
    14. 14. What is an object? <ul><li>An object is grouping of data and procedures that form a single business concept. </li></ul><ul><ul><li>Think “Employee”, “Invoice”, “Mentos” </li></ul></ul><ul><li>Encapsulates state and behavior </li></ul><ul><li>A building block </li></ul><ul><li>Something that can stand on its own or be part of other objects </li></ul>
    15. 15. What is an object? <ul><li>Objects are typically the nouns of a business problem </li></ul><ul><li>Attributes/data that describe the object are adjectives </li></ul><ul><li>Procedures/methods that act on the object are verbs </li></ul>
    16. 16. What is an object? <ul><li>Think of it as a complete program that “talks” to other programs: </li></ul><ul><ul><li>Controlled ways to use it </li></ul></ul><ul><ul><li>Controlled ways to access its data </li></ul></ul><ul><ul><li>Mask complexity! </li></ul></ul><ul><li>Promotes reusability! </li></ul>
    17. 17. Why objects? <ul><li>The alternative is data-process analysis </li></ul><ul><ul><li>End-to-end, “this is what I need” </li></ul></ul><ul><ul><li>Script-type code </li></ul></ul><ul><ul><li>Not terrible for small, short lived applications </li></ul></ul><ul><li>Problems </li></ul><ul><ul><li>What if the process changes (it never does, right?) </li></ul></ul><ul><ul><li>Code written this way often becomes a “script”, where you often have to understand EVERYTHING before you can change ANYTHING. </li></ul></ul><ul><ul><li>Horrible for large scale, interconnected applications </li></ul></ul>
    18. 18. Object oriented concepts <ul><li>Rooted in the idea of breaking large business problems into smaller, more manageable ones </li></ul><ul><li>Object oriented technology is a method for modeling and building systems, especially complex systems </li></ul><ul><li>Object analysis uses an iterative approach </li></ul>
    19. 19. Object oriented concepts <ul><li>Integrates data and process </li></ul><ul><li>Models behavior </li></ul><ul><li>Hides complexity </li></ul><ul><li>Highly reusable components </li></ul><ul><li>Highly modular </li></ul><ul><li>Faster to develop </li></ul><ul><li>Simpler to extend </li></ul><ul><li>Easier to maintain </li></ul><ul><li>Effective traceability, testability </li></ul>
    20. 20. quiz! <ul><li>Dividing business problems into smaller, more manageable tasks is a form of object oriented analysis? </li></ul><ul><ul><li>True </li></ul></ul><ul><ul><li>False </li></ul></ul><ul><li>It is often desired that a single object contain knowledge and responsibility for multiple business concepts. </li></ul><ul><ul><li>True </li></ul></ul><ul><ul><li>False </li></ul></ul>
    21. 21. Fundamental object concepts <ul><li>Encapsulation </li></ul><ul><li>Abstraction </li></ul><ul><li>Inheritance </li></ul><ul><li>Polymorphism </li></ul>
    22. 22. Encapsulation Slicing and dicing of business concepts into smaller, more manageable pieces
    23. 23. Encapsulation <ul><li>Packaging related data and procedures together </li></ul><ul><li>Or, holds the responsibility for describing (adjectives) and operating against (verbs) a single business concept (noun) </li></ul><ul><li>Does not need to be a 1:1 ratio of database tables to objects </li></ul><ul><li>Promotes information hiding </li></ul>
    24. 24. Encapsulation <ul><li>Information hiding? </li></ul><ul><ul><li>When viewed from the “outside”, visibility is limited to: </li></ul></ul><ul><ul><ul><li>What the object can do (verbs) </li></ul></ul></ul><ul><ul><ul><li>What the object knows (adjectives) </li></ul></ul></ul><ul><ul><li>The “how” details and complexity is purely internal </li></ul></ul><ul><ul><li>Controls access to data! </li></ul></ul>
    25. 25. Encapsulation <ul><li>Scope control </li></ul><ul><ul><li>Does an object describe too much? </li></ul></ul><ul><ul><ul><li>Should it be broken into multiple objects? </li></ul></ul></ul><ul><ul><li>Does an object describe too little? </li></ul></ul><ul><ul><ul><li>Is a single business concept/operation broken across multiple objects? </li></ul></ul></ul><ul><li>There is such a thing as going too far! </li></ul><ul><ul><li>Academic world vs. real world </li></ul></ul><ul><ul><li>“ Purist” view vs. reality </li></ul></ul>
    26. 26. Encapsulation <ul><li>For example: Mentos </li></ul><ul><ul><li>Adjectives </li></ul></ul><ul><ul><ul><li>Sugar </li></ul></ul></ul><ul><ul><ul><li>Glucose syrup </li></ul></ul></ul><ul><ul><ul><li>Hydrogenated coconut oil </li></ul></ul></ul><ul><ul><ul><li>Gelatin </li></ul></ul></ul><ul><ul><ul><li>Dextrin </li></ul></ul></ul><ul><ul><ul><li>Natural flavor </li></ul></ul></ul><ul><ul><ul><li>Corn starch </li></ul></ul></ul><ul><ul><ul><li>Gum arabic </li></ul></ul></ul><ul><ul><li>Methods </li></ul></ul><ul><ul><ul><li>React </li></ul></ul></ul>
    27. 27. Encapsulation <ul><li>For example: Diet Coke </li></ul><ul><ul><li>Adjectives </li></ul></ul><ul><ul><ul><li>Carbonated water </li></ul></ul></ul><ul><ul><ul><li>Caramel Color </li></ul></ul></ul><ul><ul><ul><li>Aspartame </li></ul></ul></ul><ul><ul><ul><li>Phosphoric acid </li></ul></ul></ul><ul><ul><ul><li>Potassium benzoate (to protect taste) </li></ul></ul></ul><ul><ul><ul><li>Natural flavors </li></ul></ul></ul><ul><ul><ul><li>Citric acid </li></ul></ul></ul><ul><ul><ul><li>Caffeine </li></ul></ul></ul><ul><ul><li>Methods </li></ul></ul><ul><ul><ul><li>React </li></ul></ul></ul>
    28. 28. Encapsulation <ul><li>Objects may reference other objects </li></ul><ul><ul><li>It is perfectly acceptable that a top level object has responsibility broad business concept (a master), that references one or more subordinate objects of smaller scope (details). </li></ul></ul><ul><ul><li>A bottle object may contain a liquid of type Diet Pepsi </li></ul></ul>
    29. 29. Encapsulation Pop Quiz! <ul><li>Concealing all data is the idea behind “information hiding” </li></ul><ul><ul><li>True </li></ul></ul><ul><ul><li>False </li></ul></ul><ul><li>An object has the responsibility for describing and operating against a single business concept </li></ul><ul><ul><li>True </li></ul></ul><ul><ul><li>False </li></ul></ul>
    30. 30. Abstraction When you don’t care about any specific business concept
    31. 31. Abstraction <ul><li>Purely organizational </li></ul><ul><li>Independent of implementation </li></ul><ul><ul><li>The “what”, not the “how” </li></ul></ul><ul><li>Emphasis is on standardization (and agreement) of functionality between objects </li></ul><ul><ul><li>Think common behaviors </li></ul></ul><ul><ul><ul><li>Input </li></ul></ul></ul><ul><ul><ul><li>Processing </li></ul></ul></ul><ul><ul><ul><li>Output </li></ul></ul></ul>
    32. 32. Abstraction <ul><li>For example: </li></ul><ul><ul><li>Mix two objects in a container and observe the results </li></ul></ul><ul><ul><ul><li>It is desired to use the same verb ( “react” ) to perform this operation </li></ul></ul></ul><ul><ul><ul><li>Different objects may implement this very differently </li></ul></ul></ul><ul><ul><ul><li>This is now a common behavior across all objects, regardless of how or where the data is obtained </li></ul></ul></ul><ul><ul><li>We don’t care what happens next (okay, yes we do),, simply that it is done using a “react” method </li></ul></ul>
    33. 33. Abstraction <ul><li>Taking it a step further into development: </li></ul><ul><ul><li>We know similar classes load data via a “get” method </li></ul></ul><ul><ul><li>Classes may need to accomplish this differently (some from the database, others from XML, still others from web services) </li></ul></ul><ul><ul><li>We don’t care; it is known that this “get” method will load the data </li></ul></ul><ul><ul><li>Known as an “interface” in .NET </li></ul></ul>
    34. 34. Abstraction <ul><li>An “interface contract” is an agreement between services (or developers) that a method will take certain parameters and return certain results </li></ul><ul><li>The details of “how” is done later </li></ul><ul><li>Developers can work concurrently on both services, “coding to the interface”! </li></ul>
    35. 35. Service developer’s “stub” object(s) c lass Mentos : IReactiveSubstance { public string ReactiveSubstance() { return &quot;Caffine&quot;; } public void React() { throw new NotImplementedException(); } } Interface Contract public interface IReactiveSubstance { string ReactiveSubstance(); void React(); } c lass DietPepsi : IReactiveSubstance { public string ReactiveSubstance() { return &quot;Natural Flavors&quot;; } public void React() { throw new NotImplementedException(); } }
    36. 36. class Bottle { private IReactiveSubstance _Liquid; private IReactiveSubstance _ObjectThatDoesntBelongHere; public Bottle( IReactiveSubstance liquid, IReactiveSubstance candy) { _Liquid = liquid; _ObjectThatDoesntBelongHere = candy; } public string Combine() { _Liquid.React(); _ObjectThatDoesntBelongHere.React(); return _Liquid.ReactiveSubstance() + _ObjectThatDoesntBelongHere.ReactiveSubstance(); } } Consumer developer’s code implementing and manipulating a n d m a n i p u l a t i n g both objects
    37. 37. Abstraction <ul><li>The point is, any object that “implements” the IInterface interface must implement the React() method. </li></ul><ul><li>Disciplined development </li></ul><ul><li>More importantly; if we know/design how objects will communicate with one another, they can be developed at the same time! </li></ul>
    38. 38. Abstraction Quiz! <ul><li>Abstraction is more about writing queries and code than describing how objects will communicate with one another? </li></ul><ul><ul><li>True </li></ul></ul><ul><ul><li>False </li></ul></ul><ul><li>An “interface contract” is an agreement of what method signatures will be used to read data or invoke functionality. </li></ul><ul><ul><li>True </li></ul></ul><ul><ul><li>False </li></ul></ul>
    39. 39. Inheritance Associating common behaviors to like objects
    40. 40. Inheritance <ul><li>Groups of objects that logically have behaviors in common </li></ul><ul><li>Broken down into generalization (ancestor) and specialization (descendant) </li></ul>
    41. 41. Inheritance Behaviors: React ReactiveSubstance Behaviors: React ReactiveSubstance Behaviors: React ReactiveSubstance Common behaviors: React ReactiveSubstance
    42. 42. Polymorphism Modifying ancestor behavior, one method at a time
    43. 43. Polymorphism <ul><li>Used in conjunction with Inheritance </li></ul><ul><li>Uses an ancestor’s method (signature) and alters behavior </li></ul><ul><ul><li>Called “Overriding” </li></ul></ul><ul><ul><li>Can use some or none of the ancestor’s behavior, or control when the ancestor’s behavior is called. </li></ul></ul>
    44. 44. Polymorphism Implement React & ReactiveSubstance differently Behaviors: React ReactiveSubstance
    45. 45. Inheritance and Polymorphism Pop Quiz! <ul><li>Inheritance is consolidating common functionality in an “ancestor” class that “descendant” classes get “for free”. </li></ul><ul><ul><li>True </li></ul></ul><ul><ul><li>False </li></ul></ul><ul><li>Polymorphism is all about extending or replacing ancestor functionality in a descendant class. </li></ul><ul><ul><li>True </li></ul></ul><ul><ul><li>False </li></ul></ul>
    46. 46. Review
    47. 47. Basic object concepts <ul><li>Encapsulation </li></ul><ul><ul><li>Division of information, information hiding, controlling access </li></ul></ul><ul><li>Abstraction </li></ul><ul><ul><li>Specifying what needs to be communicated, leaving the details for later </li></ul></ul><ul><li>Inheritance </li></ul><ul><ul><li>Organizing like concepts into a hierarchy </li></ul></ul><ul><li>Polymorphism </li></ul><ul><ul><li>Modifying inherited behaviors </li></ul></ul>
    48. 48. Questions???