Rethinking Object Orientation


Published on

Rethinking Object Orientation - By Kathleen Dollard

Decades after object orientation design altered programming, it’s still evolving, and we’re still learning to use it better. Many changes in the tools we use and how we write applications affect the approach we take to OOD. Some of these changes relate to architecture where approaches like SOA and the layering revolution behind Silverlight alter the place of traditional OOD within the bigger picture of architecture. Other changes are language improvements that alter the very meaning of the phrase “object” from a design point of view. Language features that alter our implementation of logical objects include generics, extension methods, delegates/lambda expressions, partial classes/methods, reflection, anonymous types, and declarative programming.

We’ll also explore the growing role of interfaces as a contractual base in composable applications and explore differences between traditional applications and ecosystem empowering applications. I’m really excited to give this talk to a group with diverse skillsets! Come ready for multi-way conversations because I want to learn from you.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Rethinking Object Orientation

  1. 1. Rethinking Object Orientation<br />Kathleen Dollard<br /><br /><br />
  2. 2. Without passion, nobody is interested. Without responsibility, nothing will get done…If passion isn’t aroused, not much is going to happen, and responsibility will never have a chance. <br />From Open Space Technology website<br />
  3. 3. Auctioning a Dollar<br />
  4. 4. Auction of One US Dollar<br />Real auction - real money<br />Whoever bids highest buys the dollar<br />Gives me what they bid<br />Gets the dollar<br />Whoever bids next highest<br />Gives me what they bid<br />Gets nothing<br />
  5. 5. The Point of the Auction<br />Individual decisions that are correct in context can lead to negative outcomes<br />This is especially true of incremental decisions extending past decisions<br />You have working software with ugly difficult to maintain code to accomplish a task. Today you need to make a very small change that will slightly increase the code’s complexity. Do you refactor it? <br />A core decision is whether to learn a technique<br />
  6. 6. Fast Track History and Basics<br />
  7. 7. Where did we start?Four Pillars of Object Oriented Design<br />Abstraction<br />Logical boundaries in a fluffy space<br />Discrete, well defined entities<br />Encapsulation<br />Secretive internals to objects<br />“Black Box”<br />Inheritance<br />Objects are specializations of other concepts/objects<br />Objects share across specialization<br />Polymorphism<br />Interchangeability<br />Common features recognized<br />
  8. 8. Where did we start?Types of Relationships<br />“Is a”<br />My Subaru is a car<br />My pet is a cat<br />“Has a”<br />My Subaru has an engine<br />My cat has fur<br />“Uses a”<br />My Subaru uses a roadway<br />My cat uses my couch to nap and shed fur on<br />
  9. 9. Where did we start?A Few Basics<br />Public<br />Billboard, sky writing<br />Protected<br />No real world analogy<br />Friend (Internal)<br />Notes on my refrigerator<br />Protected Friend<br />Union Protected and Friend<br />Private<br />My private journal<br />Quality of code matters<br />Metaphors essential<br />Good routines and classes<br />Self-documenting<br />Short<br />Strong cohesion<br />Sin better than SinAndTan<br />Sine even better<br />Few order dependencies<br />Loose coupling<br />Scope<br />Code Complete<br />
  10. 10. Logical Biz Object<br />BizBase<br />IPersistenceProvider<br />ExtensionMethod<br />1980’s<br />2009<br />BizBase(Of Tentity)<br />IValidationProvider<br />ExtensionMethod<br />IAuthorizationProvider<br />ExtensionMethod<br />ProjectBizBase(Of Tentity)<br />IFieldProvider<br />ExtensionMethod<br />Customer<br />Constructor<br />Timeline<br />
  11. 11. SOLID (Bob Martin)<br />SRP: Single Responsibility <br />One reason to exist, one reason to change <br />OCP: Open Closed Principle <br />Open for extension, closed for modification <br />LSP: Liskov Substitution Principle <br />An object should be semantically replaceable for it&apos;s base class/interface – it should do the same thing<br />ISP: Interface Segregation Principle <br />Don&apos;t force a client to depend on an interface it doesn&apos;t need to know about <br />DIP: Dependency Inversion Principle <br />Depend on abstractions, not concrete detail or implementations<br />
  12. 12. OO Extended By…<br />Interfaces and contracts<br />Multiple assemblies <br />InternalsVisibleTo attribute<br />DependencyProperties<br />Perf and virtual table issues<br />Generics <br />Reflection<br />Intellisense<br />Partial classes<br />Partial methods<br />Extension methods<br />Lambda expressions<br />Anonymous types<br />Declarative - XAML<br />WPF<br />Declarative – LINQ<br />Dynamic languages<br />Functional languages<br />Silverlight<br />Parallel entities<br />N-Tier<br />Sheer magnitude<br />Application code generation<br />SOA (Service Oriented Architecture)<br />Semantics and canonical messages<br />Workflow<br />Rules engines<br />Aspect oriented programming<br />Assembly organization<br />Designers (Property & UI)<br />Design Patterns<br />Unit testing<br />Refactoring<br />Overloads<br />Annotation:<br />See more at December, 2007 (see notes in a few slides)<br />
  13. 13. In a Service/Workflow World,Do Objects Matter?<br />“Objects” are distinct from services<br />Wrapping objects is fragile –objects != services<br />Object thinking remains important orthogonal to process<br />Granularity is essential<br />Flexibility is essential<br />Evolution is essential<br />Conceptualization is essential<br />Reuse is essential<br />Yes, they matter because they help get the job done<br />If their getting the job done, they must be written well to allow reasonable maintenance<br />
  14. 14. MEF = Managed Extensibility Framework<br />Open set of extensions<br />Custom additions to application<br />Don’t have to know finite set ahead of discovery<br />Encourages ecosystem<br />Um, so what is it?<br />Plug-in enabler<br />Compositional engine<br />Dependency injection / inversion of control – sort of<br />Car object not responsible for wheels they just show up <br />MEF is not registration based<br />Manages unknown things while IOC manages known things<br />What’s it made of?<br />Consists or parts that has exports and imports<br />Extensions can be extended<br />Can provide extensions what they need<br />
  15. 15. Word Highlighter<br />Back color<br />DSL Syntax<br />MEF: Managed Extensibility Framework<br />Intellisense extensions<br />Text Coloration<br />Start page<br />Composition Container<br />
  16. 16. MEF Requests<br />Part<br />Part <br />I have an “x”<br />I need an “x”<br />Part <br />Part B<br />Part A<br />
  17. 17. Notes added morning after talk (1 of 2)<br />Thank you for coming. I enjoyed it. I learned a lot from Dave’s talk and I think it’s important to understand and express that range. We are all part of creating IT business value. That takes perspective (Dave) and code (me). I liked that we covered that range. <br />One approach to managing complexity is “Kathleen’s Happy Place” where we have actual tools for sharing and expressing architecture based on well-known metadata patterns. But, I neglected to discuss other approaches, if you see/imagine/vision more, please email me<br />Refuse to uptake. This is the pattern emerging in the industry. I am still asked to give my generics talk. It’s four years old and I’ve given it about 30 times. WPF uptake is slow and it’s a good technology. WCF generally has uptake only when there is a real service need. Sometimes this is because of technology issues (WF and EF), but more often it’s simply the inability to get our jobs done and uptake<br />This is bad for the industry. In general, new tools/techniques allow us to do our job better<br />Today we are writing a vast amount of code that is of legacy quality on the day it is written<br />Work in teams/network. .NET killed the hobbyist programmer. I drew the curve where the amount of time to learn meets available time with productivity approaching zero. The hobbyist programmer was “canary in a coal mine”. Hobbyists programmed and had unrelated jobs – the grip, pet store owner, radio sales manager, advisor to Canadian politicians. They were (in industry, not humanitarian terms) expendable. Today we are fast losing one person shops. No one can be competent, but today teams can still be competent. This will not last forever if the curve continues to increase because communications limits team efficacy <br />A corollary of the previous – hire experts. Not people who claim to be experts, but the best people in the world in areas of concern<br />Build in a full 50% resources for technology spiking in a combination of dedicated experts and committed percentage of every person in the chain’s time<br />Training almost completely fails for many reasons here. <br />
  18. 18. Notes added morning after talk (2 of 2)<br />Build process, reduce friction, minimize inefficiencies, but know that’s a temporary stop gap measure<br />Find heroes to follow<br />You must be selective in what you bother with. One way to do that is to select, respect, and turnover the people you listen to. If Glenn Block is doing it, I want to know about it (although that’s leaning way past the bleeding edge). Listen to DNR and especially Hanselminutes on you commute<br />Quit<br />I know it sounds depressing to say, but there are careers that are less insane than ours will be in the next five years<br />I felt that composability (MEF) is an important enough architectural change to call out in an architecture group. It’s new thinking for solution architects. Perhaps I can speak on this topic in a future meeting. <br />I don’t think I put my full list of change items on my blog, or perhaps I exaggerated. But a lot has been added in the last 18 months. I talked about this list on DNR #171<br />I stopped creating this list when I realized it was fractal. What I mean by that is as you look at it under increasing zoom, it becomes more complicated, it became non-interesting as it seemed I would add things forever. However, I have considered returning to update it with announcements in the last 18 months. <br />
  19. 19. <ul><li>
  20. 20.
  21. 21. Ask Kathleen,
  22. 22. April 2008 for System.AddIn discussion
  23. 23. April 2009 for MEF discussion
  24. 24. Also Bill McCarthy and Bill Wagner’s columns
  25. 25. Hanselminutes: #152 March 5, 2009
  26. 26. Also, good Bob Martin interview
  27. 27. DotNetRocks: #436 April 9, 2009 (also, #304, 171, 121, 63)
  28. 28. About MEF – Show #148 (3 times)
  29. 29. MEF download -
  30. 30. TL49 (MEF-ifyBabySmash), TL33 (Glenn Block) at PDC
  31. 31. Pipeline Builder download:
  32. 32. Video on MAF:</li></ul>Thank You!<br /><br />