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.
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. From Open Space Technology website
4. Auction of One US Dollar Real auction - real money Whoever bids highest buys the dollar Gives me what they bid Gets the dollar Whoever bids next highest Gives me what they bid Gets nothing
5. The Point of the Auction Individual decisions that are correct in context can lead to negative outcomes This is especially true of incremental decisions extending past decisions 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? A core decision is whether to learn a technique
7. Where did we start?Four Pillars of Object Oriented Design Abstraction Logical boundaries in a fluffy space Discrete, well defined entities Encapsulation Secretive internals to objects “Black Box” Inheritance Objects are specializations of other concepts/objects Objects share across specialization Polymorphism Interchangeability Common features recognized
8. Where did we start?Types of Relationships “Is a” My Subaru is a car My pet is a cat “Has a” My Subaru has an engine My cat has fur “Uses a” My Subaru uses a roadway My cat uses my couch to nap and shed fur on
9. Where did we start?A Few Basics Public Billboard, sky writing Protected No real world analogy Friend (Internal) Notes on my refrigerator Protected Friend Union Protected and Friend Private My private journal Quality of code matters Metaphors essential Good routines and classes Self-documenting Short Strong cohesion Sin better than SinAndTan Sine even better Few order dependencies Loose coupling Scope Code Complete
11. SOLID (Bob Martin) SRP: Single Responsibility One reason to exist, one reason to change OCP: Open Closed Principle Open for extension, closed for modification LSP: Liskov Substitution Principle An object should be semantically replaceable for it's base class/interface – it should do the same thing ISP: Interface Segregation Principle Don't force a client to depend on an interface it doesn't need to know about DIP: Dependency Inversion Principle Depend on abstractions, not concrete detail or implementations
12. OO Extended By… Interfaces and contracts Multiple assemblies InternalsVisibleTo attribute DependencyProperties Perf and virtual table issues Generics Reflection Intellisense Partial classes Partial methods Extension methods Lambda expressions Anonymous types Declarative - XAML WPF Declarative – LINQ Dynamic languages Functional languages Silverlight Parallel entities N-Tier Sheer magnitude Application code generation SOA (Service Oriented Architecture) Semantics and canonical messages Workflow Rules engines Aspect oriented programming Assembly organization Designers (Property & UI) Design Patterns Unit testing Refactoring Overloads Annotation: See more at msmvps.com/blogs/kathleen December, 2007 (see notes in a few slides)
13. In a Service/Workflow World,Do Objects Matter? “Objects” are distinct from services Wrapping objects is fragile –objects != services Object thinking remains important orthogonal to process Granularity is essential Flexibility is essential Evolution is essential Conceptualization is essential Reuse is essential Yes, they matter because they help get the job done If their getting the job done, they must be written well to allow reasonable maintenance
14. MEF = Managed Extensibility Framework Open set of extensions Custom additions to application Don’t have to know finite set ahead of discovery Encourages ecosystem Um, so what is it? Plug-in enabler Compositional engine Dependency injection / inversion of control – sort of Car object not responsible for wheels they just show up MEF is not registration based Manages unknown things while IOC manages known things What’s it made of? Consists or parts that has exports and imports Extensions can be extended Can provide extensions what they need
15. Word Highlighter Back color DSL Syntax MEF: Managed Extensibility Framework Intellisense extensions Text Coloration Start page Composition Container
16. MEF Requests Part Part I have an “x” I need an “x” Part Part B Part A
17. Notes added morning after talk (1 of 2) 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. 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 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 This is bad for the industry. In general, new tools/techniques allow us to do our job better Today we are writing a vast amount of code that is of legacy quality on the day it is written 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 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 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 Training almost completely fails for many reasons here.
18. Notes added morning after talk (2 of 2) Build process, reduce friction, minimize inefficiencies, but know that’s a temporary stop gap measure Find heroes to follow 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 Quit I know it sounds depressing to say, but there are careers that are less insane than ours will be in the next five years 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. 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 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.