Oops Concepts

Object Oriented Concepts An overview and refresher for technology professionals

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!

Agenda Perspectives Objects and approaches Object Oriented concepts Encapsulation Abstraction Inheritance Polymorphism Surprises!

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.)

Perspective All data processing involves: Input Processing Output Nothing more, nothing less That’s why its called DATA processing and INFORMATION technology

Another perspective… “ Divide and conquer” Put another (more applicable) way… Divide larger problems into smaller problems so they are more manageable

Why divide? Too much information! Too complicated for a Thursday evening!

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?

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

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

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

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

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

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!

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

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

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

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

Fundamental object concepts Encapsulation Abstraction Inheritance Polymorphism

Encapsulation Slicing and dicing of business concepts into smaller, more manageable pieces

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

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!

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

Encapsulation For example: Mentos Adjectives Sugar Glucose syrup Hydrogenated coconut oil Gelatin Dextrin Natural flavor Corn starch Gum arabic Methods React

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

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

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

Abstraction When you don’t care about any specific business concept

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

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

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

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”!

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(); } }

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

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!

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

Inheritance Associating common behaviors to like objects

Inheritance Groups of objects that logically have behaviors in common Broken down into generalization (ancestor) and specialization (descendant)

Inheritance Behaviors: React ReactiveSubstance Behaviors: React ReactiveSubstance Behaviors: React ReactiveSubstance Common behaviors: React ReactiveSubstance

Polymorphism Modifying ancestor behavior, one method at a time

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.

Polymorphism Implement React & ReactiveSubstance differently Behaviors: React ReactiveSubstance

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

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

Oops Concepts

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Oops Concepts (20)

Recently uploaded (20)

Oops Concepts