Design visualisation

[Rick Beaver]

Hi

I understand design patterns, their benefits, their implementation etc.

I am really struggling with visualisation of which patterns could / should be applied to a given problem in the real world.

I am working on a subsystem at the moment and I know for a fact that there are a number of patterns which would be useful but I cannot see where and how they should be used and I cannot visualise the solution.

Do you guys have any techniques you use when designing a solution? How can I break the problem down to "see" the best way of implementing something.

Design is something that doesn't come naturally, it is something I really have to work at.

In my system I know it makes sense to use the Composite / Iterator pattern and also the Observer pattern. I just can't seem to get the design down on paper...

Any advice is most welcome...

Thanks

[Ilja Preuss]

The important part to notice is that the goal of a paper design is to get well structured *code*. For that to work, when you look at the paper design you need to "see" what the resulting code will look like, and what forces and consequences will be present *in the code*. This needs *a lot* of experience.

If you don't have that experience (and you're certainly not alone with that), there are mainly two advices I can give:

First, get feedback from actual coding early and often. The less experience you have with design, the more you will need to verify your design ideas by actually coding them and *feeling* what problems you really encounter.

Of course, your code will not be very well structured at the beginning (no matter how much time you spend on the paper design - it's simply a matter of being unexperienced). The most powerful technique to overcome this problem I know is refactoring. (Actually even many of the most experienced experts today will tell you that they often refactor to patterns instead of deciding about them before starting to code. See http://www.industriallogic.com/xp/refactoring/ )

My second advice is to not work alone on this. Asking questions here already is a good start , but you would probably get even more out of it if you could work closely together with like-minded people, or ideally even work with a more experienced mentor.

I'm not totally sure about your experience level, but if you'd like to read a book on this topic, "Agile Software Development - Principles, Patterns and Practices" might be a good fit.

[Scott Ambler]

You might also find the Agile Modeling site to be of interest. It describes a range of modeling techniques and practices, and focuses on keeping things simple.

- Scott

[Rick Beaver]

Thank you for your advice both.

My starting point has been "Head First Patterns" which has opened my eyes to a lot of design principles which I have been completely negelecting.

[Rick Beaver]

In fact thinking about the way I work now - Almost all the time I am refactoring to a better design(maybe not patterns but a better design) after I have coded up an initial solution.

Perhaps that is the best technique for someone learning design. Code the solution in the simplest most intuitive way and then refactor to a good design afterwards?

I guess code->redesign->code will be slower than design->code but I guess experience will bring the latter closer.

[Ilja Preuss]

Originally posted by Rick Beaver:
Perhaps that is the best technique for someone learning design. Code the solution in the simplest most intuitive way and then refactor to a good design afterwards?

That's how I learned it, and it worked better than anything else. Well, a lot of complementary reading and discussion will still help, of course...

I guess code->redesign->code will be slower than design->code but I guess experience will bring the latter closer.

In my experience your second guess is right on, but the first one not as true as you might believe. The practice known as "evolutionary design", where most of the design emerges during coding, is quite effective, in my experience - as long as it is supported by an extensive suite of tests. Google for Test Driven Development for more...