locked
Design Patterns and Open/Closed principle help! RRS feed

  • Question

  • Whilst I've spent quite a bit of time reading about design patterns I still don't have much experience when it comes to actually implementing them.
    I (think I) understand the design patterns themselves, but as usual many of the examples given when explaining these patterns are purely academic.
    The other principle I've read a lot about but struggled to make use of is the open/closed principle.
    It's long overdue that I get stuck into making some of these patterns and principles work for me, so I'm looking for some help please.

    As a sample application, I'm looking to write a simple text editor (something I've done before) - Notepad on steroids.
    My thoughts are this...

    Objective #1; I'd like to be able to switch the actual editor component itself.
    Partly because it would be cool to switch between a plain text box and a rich text box but also because I think if I achieve that level of abstraction then I should also be able to mock my editor when it comes to unit testing.

    Objective #2; I need a set of 'features' that can be added to yet still adhere to the open/closed principle.
    Let's start with something simple, the ability to insert today's date at the current cursor position.

    So now I'm struggling with which of the many patterns/approaches I've read about are appropriate.

    Initial thoughts are that the command pattern stands out.
    The idea of encapsulating the insert date feature as a command seems logical.
    That command could be 'invoked' by a menu, a context menu or by the editor control itself (via a shortcut key sequence).
    Question 1, is it ok if the invoker of a command is also the receiver?
    Question 2, does this sound like an appropriate use of the command pattern?

    Final question, what pattern is going to help me with the fact I don't know how many commands I may have yet?
    I've already partially built a sample application that follows the above.  I didn't finish it because I'm not entirely sure I'm setting out on the right path.
    My confusion is based on the fact that all of the samples built around the command pattern seem to know how many commands are in their scenario.
    In my world, however, if I map features to commands like this then I don't know how many commands there will in a future release.
    I would really love to stick to the open/closed principle here, but I just can't see the wood for the trees.


    Thanks in advance to anyone who can offer me any advice or guidance.



    Chris.


    MQCA
    Tuesday, June 1, 2010 4:25 PM

All replies

  • Have a look at the advice from my thread, I think you'll find it useful; http://social.msdn.microsoft.com:80/Forums/en-US/architecturegeneral/thread/5934571c-6517-4310-9692-820399370612

     


    http://pdkm.spaces.live.com/
    Wednesday, June 2, 2010 6:18 AM
  • Hi MQCA,

    I agree with the fact that the design pattern examples given on the sites looks more of academic and when it comes to implement design pattern on real time problem it becomes challenging. 2 months before, I was on your state struggling to identify which pattern would suite best for a given problem and finally I ended up writing a console app to work exactly like MS command prompt. Initially I supported 4 commands to that. By that time I knew only Abstract Factory and Strategy pattren the most, so I built my application in abstract factory pattern. But once my application was over I ended up getting lots of loop holes and areas which could be highly optimized. So I felt like using singleton pattern to ensure object of each command type is created only once and I kind of achived that.

    So my advise would be the same to you. Start implementing your app in the pattern you best know and then think about it taht how well you can optimize it using different pattern if possible.

    BTW I would love to see you code snippet you used in your app which can actually give me some input to my code to make it better since idea of both the codes is similar. I hope we can do that.

    Thanks

    Wednesday, June 2, 2010 7:37 AM
  • If you look at WPF application.commands that will have quite a number of the editing commands you'll want already.

    Commanding works really well in WPF since it's a first class fundamental part of the thing.

    Plus if you really like open/closed then you have attached properties and behaviours.

    Bear in mind that patterns are labels applied to approaches.   You probably already use patterns without even knowing they're a pattern if you've been developing for some time. 

    I think that top down design is a good idea and knowing roughly what your application will do before you start is a must.  On the other hand many details don't really matter too much.  If you forget to list your reverse-string command then is it really a big deal?   You don't want some application that starts out neat but grows topsy turvey into a completely different shape than you originally envisioned.  That sort of development usually involves compromises and pain.  There again if you get a fair idea of the overall design but miss a couple of minor details then I would have thought they can fit in easily.

    Wednesday, June 2, 2010 11:07 AM