Skip to Content

Real-world discrepancies
Everyone’s talking about methods and concepts helping in making the development of sofware easier and more fruitful. Design Patterns are supposed to help as well. But there seems to be a discrepancy between academical research activities and practical use of patterns in pofessional software development.

In academia, patterns are a hot topic producing uncountable publications and creating highly-paid chairs. In industry, my observations and interviews indicate a *slightly* different picture: Nearly none of the object-oriented developers uses patterns. And if, then the easiest of patterns to be known. Frameworks injected in a company’s software product deliver Design Patterns to some extent. One reason might be that framework developers are usually more competent than “ordinary” developers or programmers doing their job.

SAP world introspected
In case of SAP developers the situation is even worse. Having programmed with ABAP all night and day, ALMOST NO ONE of them basically knows what a Design Pattern is. Am I wrong? Then give me a comment on this blog. But most probably my assumption should be correct.
On the other hand, patterns play an important role in NetWeaver, as for WebDynpro the concept of UI patterns is being introduced to develop applications more intuitively.

Getting on it
I’ll tell you something concrete about my strong assumptions being covered by many interviews, references and personal impressions on several software projects:

  • 90% of all developers don”t know about the existence of Design Patterns.
  • 10% of all developers use Design Patterns.
  • Only 1% of all developers (or one tenth of the 10% mentioned above) invent new Design Patterns or variations from known ones.

The journey into success
As John Vlissides (member of the Gang of Four, GoF) said, there are six phases to climb the hill of being able to successfully (in our words: profitably) use Design Patterns. After having understood what they are, you begin to work with them, play with them. After a while you know more than two or three patterns. After that you even understand why they are implemented in their specific way. But only the last step brings you into a position embracing you to use them to your advantage. Before that everything you do is – more or less – a waste of time (or boondoggle, like this word).

Conclusion
The concept behind Design Patterns has been proven useful. It has been adapted from the well known architect Christopher Alexander, who invented the concept for use in architecture. Now we are searching for ways of creating mechanisms and tools to help us to cope with Design Patterns more effectively. The effort in learning them up to the point that enables us to use them as a daily tool is not acceptable. The community of developers needs something to overcome this antagonism. Here, we need academia to lay ground and industry to sponsor projects and give feedback and new impulses as well!

Resources
Here are some links in addition to the one at the top of the article concerning Design Patterns:

http://de.pinterest.com/pin/create/extension/

To report this post you need to login first.

20 Comments

You must be Logged on to comment or reply to a post.

    1. Klaus Meffert Post author
      Hello Craig,

      of course you are right: I added a link to a resource concerning patterns.
      Additionally, in the text I linked to an article from John Vlissides descibing the 6 phases to accomodate with design patterns.

      BTW: I like the URL you provided!

      Regards

      Klaus

      (0) 
        1. Klaus Meffert Post author
          Hello Craig,

          could you tell me which patterns you have used (Singleton, Factory Method, Observer etc.)? In which language (ABAP, Java C++ ..)? Did you feel comfortable using them/was it easy/did it help improve your code and architecture?

          Would love to hear from you 🙂

          Regards

          Klaus

          (0) 
          1. Craig Cmehil
            To be honest for the most part I use them now without thinking about. I would say “Facade” is a major one for me but also “Singleton”. But I’ve tried most with both Delphi, Java and PHP as well as general Project management and problem solving. As for comfortable I would say yes, I mean after awhile of using them you don’t tend to “think” about using them you just do. Kind of like me learning German after awhile you stop translating you just know it.

            It does help improving your development process but at the same time it can also get in the way. I’ve know others that try to apply them to just about everything even when it’s just not necessary. Like anything with programming you need to find the balance.

            Another link for those wanting more info:

            http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/EspPattlets.asp

            Yep Microsoft themselves have a nice little list.

            (0) 
  1. Klaus Meffert Post author
    I extended the original article by a resources section. It includes the links posted in the comments as well as some few more. With this you should have a good start on Design Patterns. As a professional, the ObjectMentor link should be interesting for you.

    Cheers

    Klaus

    (0) 
    1. Ivaylo Mutafchiev
      It’s my 2nd trial to post on this blog. I’m not sure where 1st one went to.

      As a developer who came to SAP/Abap from a pure object-oriented environment (IBM VisualAge Smalltalk) I could say I used design patterns widely in my OO programming experience – can’t say for sure which of them, perhaps most of them. Okay – I used double-dispatch pattern for sure for 1st time when implemented own Currency/Quantity mathematic and needed to deal with another objects in the Number hierarchy.
      They made your life easy – means code is clearer, shorter and meaningfull – when you know how to apply them and you do apply them in a correct place. For me OOP is tiny connected with design patterns – in order to be good/productive architect/designer/developer, you should use them.
      I would suggest to the community few of sources I’ve used (not connected with Smalltalk specificaly, but with OOP principles):
      1. “Design Patterns Elements of Reusable Object-Oriented Software” – by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
      (the Gang of Four 😉 ) – you can access it at: http://hillside.net/patterns/DPBook/DPBook.html
      2. “The Design Patterns Smalltalk Companion” by Sherman R. Alpert, Kyle Brown, Bobby Woolf, published by Addison-Wesley

      Klaus, nice blog! Thank you!

      Ivaylo

      (0) 
    2. Ramprasad Rai
      In my case, I heard of  Design Patterns slightly later in my career, couple years after I  started writing programs.  That didn’t hurt that bad, in fact I had better appreciation for them and, I  put them to use immediately ..as if I was waiting for them:).

      I used some these ideas without knowing these were “patterns”. Personally I have a  passion for code reuse and to try to do more with less;). Exposure Borland, MFC library C++ source code and lot of other cool stuff. So this might be why I like the idea so much.

      If you ask me which patterns I can remember “Singleton”, “Delegate” pattern [I hope I got  the name right]. I had my own “factory” pattern in a slightly crude form, with  same goal though. There is another “pattern” I use all the  time…thanks to MFC where they instantiate classes representing window[Windows window]  objects in a way that, there is a constructor that does NOT do much and but there is a separate ‘create’  method where much of the action occurs[ e.g. creating the real windows window object]. It is easier to manage errors in a ‘create’ method than in class constructors.

      In addition I had my own version of iterator, command patterns. Point is if one looks to optimize his  coding, one ends of using “patterns” anyway, problem is time and effort.

      My 2 cents:-)

      (0) 
  2. Armin Reichert
    Hello Klaus,

    thank you for directing the focus on the important topic of design patterns. With about ten years of research I would not really consider this a “new” topic.

    If you sail on the large ocean of software at SAP, you will surely find islands populated by the various design patterns.

    Let’s take a look at the Web Dynpro UI Element library named “Core”.

    The “Core” library is the foundation of all existing and future Web Dynpro UI element libraries because it provides the base classes/interfaces that all other library elements must extend/implement.

    Being a very small island with only 6 inhabitants I think it is nevertheless an interesting place.

    The inhabitants are called “ViewElement”, “UIElement”, “UIElementContainer”, “Layout”, “LayoutData” and “Visibility”.

    What are their roles?

    ViewElement represents an abstraction for an “adressable thing living in a view”. So it provides an identifier and holds a reference to its containing view. The view itself stores a map of all its view elements such that one can efficiently find each view element by its identifier.

    UIElement is a subclass of ViewElement augmenting it with some common properties, namely “enabled”, “visible” and “tooltip”. Their meaning should be obvious.

    UIElementContainer is a subclass of UIElement adding the properties “width” and “height”.

    To be able to create containment hierarchies, UIElementContainer provides a (bidirectional) aggregation to class UIElement named “Children”. Because UIElementContainer is a subclass of UIElement, one can nest UIElementContainers into each other and create arbitrary deep containment hierarchies.

    Here you have the Pattern 1: “Composite”

    The “children” of a UI element container may be traversed without knowing the internal storage data structure. To allow this, UIElementContainer provides a method iterateChildren() that returns an iterator object.

    So we get Pattern 2: “Iterator”

    The children of a UIElementContainer can be rendered in a number of predefined ways. So you need a “strategy” of how to achieve this:

    Each UIElementContainer aggregates a Layout object whose implementation defines the algorithm used to layo out the container’s children. In general, a child managed my a certain layout, must store some LayoutData, e.g. a position in a coordinate system.

    During runtime, the application can change the layout of a container by setting a different Layout object and providing the children with the corresponding layout data.

    So we get Pattern 3: “Strategy”

    A Web Dynpro application is completely shielded from the implementation classes of UI element libraries. To achieve this, each library element provides a public interface, these IWD-things like IWDButton. One might consider this as a very simple case of

    Pattern 4: “Facade”

    But if you can only see interfaces of UI elements, how can you create instances? You cannot use the “new”-Operator because the implementation class is not visible to the application. What you need here, is

    Pattern 5: “Factory”

    In the current Web Dynpro Java Runtime, we use the  view as a generic factory. That means you pass the public interface of a UI element to a factory method together with an identifier, and you get an instance of the implementation class.

    Example: How to create a button with ID “buzzer”?

    IWDButton buzzer = (IWDButton)
      view.createElement(IWDButton.class, “buzzer”);

    Let’s stop here, perhaps one should better write a Weblog about this topic.

    My point is:

    If you *design* a set of collaborating classes, you naturally come in touch with the basic design patterns.

    But this does not happen automatically. You must *know* about patterns, must *think* in terms of them and must *play* with variants of them to really get a benefit, IMHO.

    Armin Reichert
      

    (0) 
    1. Klaus Meffert Post author
      Hello Armin,

      thanx a lot for your long comment on the subject of Design Patterns.

      As you said, Patterns are an old subject. To my concrete knowledge Bertrand Meyer mentioned something comparable in the 1980’s. Yet it is a quite old matter, it seems interesting enough for SAP to get involved in it.

      I totally agree with your remark that knowledge of Design Patterns and the ability to use them “does not happen automatically. You must *know* about patterns, must *think* in terms of them and must *play* with variants of them to really get a benefit, IMHO”.

      Perhaps this the most interesting point: How is one lead to know and be able to apply (Design) Patterns? Which tools should help the developer (if not even persons on a more abstract level)?
      IMTTNSHO (In my this time not so humble opinion) SAP’s way of offering tools support for patterns in general is a good one (declarative development of UI’s).

      Regards

      Klaus

      (0) 
  3. Dale Seng
    The tendency from people (that probably don’t even use them) is to start calling everything a design pattern.  This is, to a great extent, where the hype comes from.

    With respect to taking a lot of tinkering before becoming valuable, yes, I agree 100%.  After reading the GoF book, I was lost on all but about 4 patterns.  But have found I can think in quite a few patterns now.  It took time and (especially important) seeing examples of how patterns were applied (by somebody smarter than I).  But yes, it takes a lot of time.  Is it worth it?  I think that depends on whether you want your code to be an art form (back to the elegance versus functionality debate that dates back to the first programs ever written).

    –Dale–

    (0) 
  4. Homam Alsayed
    Klaus,

    I agree with you in general. I would even venture to say that less than 10% of object-oriented developers (note the OO qualification) *conciously* use patterns.

    Sure, patterns are used more by API and framework designers because the GoF patterns are geared mainly toward this category.

    (0) 
  5. Anonymous
    Just one thought – you don’t invent patterns. patterns are proven solutions to well-known problems. Hopefully, the SAP programmers use such proven solutions. One idea of patterns is to capture and share such knowledge. However, it seems to be hard for an expert to explain (and write down) his nifty day-to-day tricks.

    Internally, we are doing this for security (in the security area you can see many well-known problems and most people are happy to apply a proven solution in the 1st run) – the product standard security describes solutions for common problems – we don’t call this patterns.

    (0) 
    1. Klaus Meffert Post author
      Markus,

      I agree with you that it is problematic to talk of “inventing patterns”. They evolve and represent templates/solutions to sort of recurring problems.

      But in my opinion, the definition of a design pattern could be extended/modified. Someone being ingenious could think of a cool mechanism to solve a certain problem. He documents it. Then, it is not yet a pattern, in your opinion (it only can be called a pattern after approved usage).

      This seems kind of philosophical to me. I would therefor allow the term of inventing patterns.

      Regards

      Klaus

      (0) 
    2. Klaus Meffert Post author
      Markus,

      I agree with you that it is problematic to talk of “inventing patterns”. They evolve and represent templates/solutions to sort of recurring problems.

      But in my opinion, the definition of a design pattern could be extended/modified. Someone being ingenious could think of a cool mechanism to solve a certain problem. He documents it. Then, it is not yet a pattern, in your opinion (it only can be called a pattern after approved usage).

      This seems kind of philosophical to me. I would therefor allow the term of inventing patterns.

      Regards

      Klaus

      PS: I posted this comment beforehand but with the first posting it did not appear in the weblog but only on the list of recent comments. Perhaps it helps with bug fixing that I tell you that before posting my comment some time passed by.

      (0) 
      1. Klaus Ziegler
        Hello Klaus,
        I think the term ‘extending/modifying’ patterns needs clarification. From my point of view patterns offer 2 big advantages:

        First, they provide you with a way to solve issues using a proven solution.

        Second, design patterns make communication more efficient. Developers can immediately picture the high-level design in their heads when they refer the name of the pattern used to solve a issue.

        If a pattern is modified (or in case of a pattern inflation) again each solution has to be explained in detail.

        (0) 
      2. Klaus Ziegler
        Hello Klaus,
        I think the term ‘extending/modifying’ patterns needs clarification. From my point of view patterns offer 2 big advantages:

        First, they provide you with a way to solve issues using a proven solution.

        Second, design patterns make communication more efficient. Developers can immediately picture the high-level design in their heads when they refer the name of the pattern used to solve a issue.

        If a pattern is modified (or in case of a pattern inflation) again each solution has to be explained in detail.

        (0) 
        1. Klaus Meffert Post author
          Hello Klaus (sounds to me if I am greeting myself 🙂 ),

          I don’t see why extending or modifying a pattern equals an antipattern. Perhaps one has to distinguish between two modes:

          Firstly, a pattern can be modified by altering its code and or structure individually.

          Secondly, a pattern can be modified by combining it with other patterns. For instance, take Observer with Strategy and Change Manager. For the latter, the resulting pattern could be called “Flexible Observer” or whatever. This is a new pattern as Observer was modified and extended by the introduction of Strategy. But Observer can still be identified as can be Strategy. I don’t see what’s wrong with this.

          For the first aspect, I cannot see the difference between an – let’s name it – evolved pattern and an original pattern, if both provide a practical solution to a problem.

          Additionally, I agree that new patterns need to be explained in detail and need to be made known to others.
          BTW: Most developers actually don’t know half of the GoF patterns (even conceptionally!). Because of this your second point seems to invalidate also most of the original patterns (as those from POSA or Fowler, too). Additionally, there are incosistencies in the description of some standard patterns between GoF and other sources.

          Regards

          Klaus

          (0) 
  6. Anonymous
    What happened with my first comment attempt? It simply vanished.
    Klaus,
    I am new to patterns and am still playing with basic ones, but still I have excellent results in ABAP OO, field that you marked especially troublesome (hopefully I’ll write a separate weblog on particularities of my work).
    I agree with all that you wrote, except that the effort in learning patterns is unacceptable, and that you have to be a pattern guru or otherwise you waste time. In my opinion, the effort needed to learn any development tool, or to accept object paradygm, is even greater. So, shall we stop developing software?
    Ofcourse, more you learn about patterns, better programs you create. But even using a few basic ones (that’s what I did – I used Adapter, Bridge, Abstract Factory and Decorator) is better than nothing, especially if the learning process continues.
    If so, where does this academy – real world discrepancy that you’re talking about come from?
    Companies rarely encourage their developers to improve their skills, because they don’t see benefit of it. When they hire a developer, they want a cheep one who creates programs which work and that’s all. And yes, they want progs to be finished yesterday. That’s short term profit that they see clearly. Profit of improving developers’ skills is invisible because it’s long term and it’s hard to see connection. There’s a gap between academic awareness and industry because of different language. Decidion making managers understand only one language: money. When somebody translates design patterns’ technical boondoggle to concrete numbers, we’ll see their rapid growth.
    Igor
    P.S. As a beginner, I was reluctant to start with GoF bible. I bought Design Patterns Explained by Shalloway, and was pleased.
    (0) 
    1. Klaus Meffert Post author
      Hello Igor,

      it is legitimate to state the effort in learning patterns is not a problem greater than get known to a development tool. Nevertheless, I have a different opinion. And as my blog writes, also John Vlissides, one of the members of the Gang of Four (that made Design Patterns in software development popular and who has not revised his opinion until now – over ten years later) is explicitely expressing his opinion that profiting from Design Patterns is a very long way to go. He says, only the mastery of the very last step on the learning ladder is bringing you into the position of profiting from them.

      Besides that learning to work with an IDE is something completely different. An IDE is representing a kind of closed system with few flexibilities and degrees of freedom, compared to Design Patterns. I don’t want to go into more detail on that comparison.

      Additionally, I am not shure whether it is so easy to master some few patterns like the ones you named (Adapter, Bridge, Abstract Factory, Decorator). This is – besides other things -because you have to caution to use the right pattern in the right context. Using a pattern in a wrong manner destroys more than it helps advance the design. Also, one needs to know differences between similar patterns, like Factory Method and Abstract Factory. Think of a similarity matrix existing only for the 23 GoF-patterns! Think of how many documented (and popular) patterns exist! How do you know which to learn and which not, how to detect dangers resp. knowledge gaps?

      My experience and many talks to professional developers give me other hints. They tell me the same that Vlissides expresses: Learning Design Patterns needs great effort.

      Regards

      Klaus
      PS: Thanx for sharing your thoughts and agreeing with the other parts of my weblog entry 🙂 I am looking forward for your weblog to come.

      (0) 

Leave a Reply