Design Patterns - Architecture Astronaut

Question

First, feel free to close this if it's not appropriate, as this is my first time on Stack Overflow.

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

MVC, in and of itself, doesn't require that you write any framework. It simply means you keep your view, controller and model code separated. I use MVC (or MVP) for even simple mobile apps as I have found the separation of control to be hugely advantageous when writing tests (not to mention when changing UIs).

My guess is that you don't do a lot of unit or integration testing right now, so it's not near as obvious how much making this division helps the quality and readability of your code.

I'd highly recommend you read Fowler's coverage of UI architectures.

Answer 2

For me, it depends on:

• The size of the application,
• The design pattern to be used,
• The amount of time I have to invest upfront in architecture.

In a small application, I'm much less likely to use any design patterns that don't flow naturally unless they have a great ROI in the scope of expanding or maintaining the application.

Answer 3

You're working in an environment where the patterns are set for you by a large company, and I think this explains your feelings. And you're probably right. Those of us using FOSS languages in open environments for broader problems have endless choices, and reading on design patterns helps us make informed decisions about architecture. Usually this means picking the right libraries. Your choices for the narrow domain you are working in have been made for you.

Answer 4

The patterns are just there as abstracted solutions to general problems. If one knows the patterns, then they have a greater likelihood of applying a known solution, faster, and not sitting around thinking, "gee, I wonder how to make this work."

Regarding frameworks: if you've worked on a team of more than one person (which it doesn't sound like you have based on the small size of your projects), frameworks can help to make everyone do things the same way, which is important in a group effort for maintainability and quickly getting new people up-to-speed.

Answer 5

IMHO one needs to have:

1. A good understanding of the pros & cons of different design patterns that you could use
2. Clarity on what your application is designed to do and make sure the pros of the pattern are used to your advantage.

Take the MVC pattern as an example. If I want to implement this pattern using WinForms or ASP.NET (VS 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.

Does your web application need effective SEO? The MVC pattern implemented for ASP.NET could help in this regard. Take SO URLs for example. They are so well optimised for search engines primarily because the MVC pattern implementation for ASP.NET supported it and has been used effectively in SO design/development.

Answer 6

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 7

'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.

Answer 8

Almost any proper design pattern, when applied, should result in simplification. If you're making things more complex, you're probably headed in the wrong direction for your specific problem.

Answer 9

Simple problems often require simple solutions although some hard problems are very simple. Complicated problems on the other hand could be solved in organized fashion or by dirty spaghetti code. Many have tried to organize the software designs and some of the "patterns" emerged and got the names.

I think patterns are useful vocabulary to have when you communicate your design intent to others, but it's not something you shove it into design. As you make your code de-coupled as needed, you apply patterns as needed. For example, putting in builder pattern when you find yourself making very complicated constructor.

De-coupling data layer and UI layer from your business logic to me is something you should do just as good design. Again, low coupling, DRY, and maintainable code should be the goal, not patterns.

Answer 10

"Architecture astronauts" are those who spend a lot of time discussing design but don't actually make any of it happen.

I like the approaches to design patterns presented in the book "Refactor to Patterns". Here, patterns are not something we invest in upfront but something we do to reduce code complexity only after it is getting in the way. Because this approach requires functional code to begin with, and selects refactorings based on what would make it easier to extend that code to meet a particular requirement, its very much results focused.

Answer 11

Don't forget about communication - well known design patterns allow you to communicate something complex with just a few words. When you say "and notifications are delivered using the Observer Pattern", everyone knows what you mean.