OO design patterns - Forum - OpenEdge General - Progress Community

OO design patterns

  • "Design patterns exist largely because of the major shortcomings of OOP languages. Many of them simply become irrelevant in other paradigms. It's not obvious how inheritance is a good thing in itself. Abstraction, encapsulation and modularity are not exclusive to OOP, but exist in most paradigms. Similarly, most paradigms have some form of polymorphism."

    "The need for DesignPatterns should be considered a LanguageSmell" 




  • I really thought of writing a decent reply to this, but why waste the time and energy on something negative, while at the same time I can be productive and write good OO code using design patterns and common sense...

  • "Waste time"? Who is being negative?!! The criticism is meant as a call for improvements in the 4GL. I assume, am almost 100% sure that you don't want to dig deeper into the critics to understand them (or are you a marketeer with really deep knowledge of informatics? No.).  That is ok, it would be time consuming. But again: just skip the message then. Don't pretend you know better, that it's a piece of cake for you with your "*yawn*" [for the record 20/9: two messages have been removed, in the one from LdF the text was no more than *yawn*]. Ditto for the likers of your message. I've experienced their shortcomings before. Patterns are tied to languages, the GoF was aware of that too. Maybe some of the patterns you use are the best solution in object-oriented oe as it is now, but would not be needed anymore with new language constructs. You could, clumsily, say that you "implement the design pattern" more elegantly by using the new construct. Don't ask me to make this clear for you, you can find things out for yourself if you are really interested. I'm not going to "waste my time", I have more interesting things to do.

      And in common on OO: If even someone with the stature of Edsger Dijkstra has questionmarks on it's elegance it could be worth to find some things out.

    Kind regards,

    Stefan Houtzager

    Houtzager ICT consultancy & development


  • I'm going to follow your advice to ignore your messages from now on. Have a great life, bye!

  • I am not sure the point you are trying to make here but Design Patterns are a valuable tool for communicating and understanding design strategies. They are not there to address short comings of OOP, but to enrich communication and problem solving. Think of them as a recipe book without quantities - they provide guidance on how to solve common problems, but leave the detail to the Designer.

    Through use of a common vocabulary - the design patterns -  time is saved and risk and ambiguity reduced.

  • I'm familiar with design patterns and oo (abl), they are valuable when you use oo abl. Agreed on that. I see them (as the GoF themselves and others) as dependent on the language used. They were written with smalltalk in mind iirc. For the rest see f.e. en.wikipedia.org/.../Software_design_pattern, the criticism chapter.

    > They are not there to address short comings of OOP

    Yes they are!

     If - after reading this chapter - you are interested in more

    watch f.e. www.infoq.com/.../Are-We-There-Yet-Rich-Hickey and

    www.youtube.com/watch (uncle Bob aka robert C. Martin).

    My point is that the 4GL could be improved with the functional paradigm. Microsoft is doing that with C# (see other recent messages of me in this communitygroup).


    Kind regards,

    Stefan Houtzager

    Houtzager ICT consultancy & development

  • OK, so nothing to do with Design Patterns at all then!

  • "Only" with the 4GL as it is now. ;-)

  • jaxenter.com/foul-mouthed-developers-which-community-curses-most-108053.html

    The winners in the positive sense are the users of a functional language. ;-)

  • My present of the day for the lovers of OO design patterns:


    with lots of pointers to other reading material.

    Kind regards,
    Stefan Houtzager
    Houtzager ICT consultancy & development
  • My present of today on the subject of the (oo, gof)  iterator design pattern (reference below, excerpt above).


    The major problem with iterators is that they are non-functional

    functions--they depend upon an internal state and side-effects to

    operate. It is very difficult to prove anything about functions with

    state, and therefore such functions inhibit most compiler

    optimizations. But the most damning criticism of iterators occurs in

    the context of multitasking and parallel threads. When using parallel

    threads, all side-effects must be protected by locks, in order to

    ensure the consistency of interpretation of the contents of shared

    objects with state. While most iterators in C++ are locally-defined

    for a particular loop, and therefore not shared with any parallel

    process, it is difficult for a compiler to prove this. As a result,

    one is either left with an inefficient program, or a potentially

    dangerous program, depending upon whether the compiler inserts locks

    to be on the safe side, or leaves them out in the name of efficiency.

    These problems do not arise with the higher-order mapping functions.

    As we have shown, mapping functions can be completely functional

    (i.e., they have no shared state or assignments), even for complex

    iterations like those for comparing the fringes of non-isomorphic

    trees. This means that an arbitrary number of mappers can

    transparently access the same collections without interference--at

    least so long as the collections are not updated. If the collections

    are also read-only, or functional, then there is no possibility of

    interference under any circumstances. Mappers create function closures

    during their operation, and these temporary objects hold the "state"

    of the iteration, much as iterator objects do in C++. The difference

    is that these closure objects are created automatically during the

    execution of the mapping functions, rather than having to be

    explicitly created by the programmer, as in C++, and the

    side-effect-free nature of mappers is obvious to a compiler based on a

    cursory syntactic scan.



  • Note that the article puts some restrictions on mappers - namely that the collections are read-only, in which case the purported shortcomings of iterators - that they're sensitive to updates of the collection in a multi-threaded environment - goes out the window. 


  • ??

    The problem with the iterator pattern is recognized by others also, solutions proposed are with generic programming in java (homepages.ecs.vuw.ac.nz/.../thesis.pdf).

    web.cse.ohio-state.edu/.../02HPS.pdf (problem named, I have not looked at solutions).

    In functional languages mappers are used. See f.e. www.braveclojure.com/.../

  • your thesis paper gets me "403 Permission Denied"

    As for the problem with the iterator pattern, that's not what the article was about. It purported that mappers were superior if the collection was read-only vs iterators which were not if the collections were updated. An apples vs oranges comparison if ever there was one.

  • > your thesis paper gets me "403 Permission Denied"

    Apparently you have to remove the ")." that are included with the URL when you click it.

    The thesis seems to discuss some extension to Java to keep track of ownership for iterators.

    I haven't read the pape yet, other than the introduction, but I notice that when the C++ Core Guidelines were presented at the recent CppCon, it too included generic features and new lint style utilities for checking ownership of pointers (including iterators).