Design Patterns - Architecture Astronaut [closed]

Question

Perhaps my question is similar in nature to this one: Do you use design patterns?

The programs that I write are small 50-75 K line programs mostly using Windows Forms and ASP.NET. These programs are GUI intensive allowing the design and layout of various graphics and graphics processing.

I consider myself good at OOP and practiced at balancing OOP and traditional procedural methods to create maintainable code.

The problem comes in when I consider design patterns. The linked to thread has an interesting comment that design patterns may be used but not intentionally. When I want to intentionally use a design pattern (in the design of my program), it feels like I'm going above and beyond what is needed, that I'm in the realm of "architecture astronaut" so I fall back to my traditional methods and everything goes along smoothly (i.e. normally).

Take the MVC pattern as an example. If I want to implement this pattern using Windows Forms or ASP.NET (Visual Studio 2005) then I have to write a "Framework" and writing frameworks seems to be more trouble than it's worth for the size of the application.

Perhaps my applications are too small to justify the use of some of these patterns. Perhaps I just don't know the patterns well enough or need to study them more.

Does anyone else experience this "architecture astronaut" feeling?

How do you go about intentionally using design patterns without going "overboard?"

Answer 1

When it comes to smaller applications of this nature, I generally worry more about anti-patterns than I do about design patterns. That said, it's really two sides to the same coin: the power of a design pattern for me is being familiar with them so as to recognize the less-than-obvious pros and cons of whatever solution I'm thinking of. I rarely if ever go out of my way to actually fully implement a complete design pattern (unless I actually need all the functionality); however, I have often saved myself a lot of future re-work by recognizing the path I'm on and looking at the common pitfalls or drawbacks to that solution, which I can then check against my future uses to see if it's going to be a relevant concern for me or not. Thus, the power of a design pattern is that you can easily predict the future consequences of your current solution against your potential needs, without worrying that you might be missing some less-than-obvious caveat or special case that you haven't considered.

Answer 2

'How do you go about intentionally using design patterns without going "overboard?"'

Easy.

1. Don't conflate an MVC framework development effort with patterns.

2. Recognize that every single thing you do has been done before (by you or someone else).

3. When you repeat something -- anything -- you're following a pattern.

4. When you repeat the design for anything -- no matter how small -- you're following a design pattern.

5. When you notice yourself repeating something, assign a name to that thing you are repeating. Look, you've discovered and named your first design pattern. No matter how small.

6. When you've named a design pattern, you can then think about when you use it, why you're using it, what it solves and what the consequences of using it are. No matter how small.

7. Every piece of learning that involves "repeating design elements" is design patterns. No matter how small.

Every loop. Every if-statement. Every dialog box. Every file open. These are all design patterns.

Most are part of the language and have obvious language-specific names. "IF", "OPEN", etc.

Some design patterns are larger than a single statement but smaller than the entire MVC framework. Those are the interesting ones. Learn those. Buy a book. Read it. MVC will not appear in most design pattern books, because -- well -- it's too complicated and too difficult to apply.

Don't start with MVC. Start with ANYTHING else.