Uploaded on

 

More in: Technology
  • 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,661
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
4

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