9

I've read this page about design patterns, and how you should treat them when writing your code. From my understanding, as the title in the link states:

Patterns are not building blocks.

If I understand correctly, this means not to use a design pattern until it makes sense to do so, correct? Don't start off saying you're going to use the Strategy Pattern, wait until you write some code, and if using the Strategy Pattern makes sense for your design, then use it.

Do I treat the MCV/MVP pattern the same way when I create GUI applications? From the respective links, it says that it's an architectural pattern.

Suppose if I create a GUI application and I don't use the MCV/MVP pattern, but my code is clean, readable, and maintainable, is it still a code smell/bad design that I didn't use the MCV/MVP pattern?

17

If I understand correctly, this means not to use a design pattern until it makes sense to do so, correct?

Yes.

Don't start off saying you're going to use the Strategy Pattern, wait until you write some code, and if using the Strategy Pattern makes sense for your design, then use it.

Yes. Technically, you may realize that the strategy pattern is appropriate before you even write any code, but that should be because you were thinking about the actual problem and designing a solution for that problem, which I assume is what you meant.

Do I treat the MCV/MVP pattern the same way when I create GUI applications? From the respective links, it says that it's an architectural pattern.

Yes, MVC/MVP/etc are architectural patterns. In one sense, that doesn't make a difference because you still should only use MVC/MVP/etc when they make sense; when it's a reasonable fit for the actual problem you're trying to solve. Where it does make a difference is that, because it applies at a much higher level than, say, the Strategy pattern, you'll typically figure out whether or not it makes sense and decide whether you're going to use it as part of your design work, before writing a lot of code.

Also keep in mind that "MVC/MVP" is not one single pattern, but a very huge family of related patterns, and there's no consensus on what exactly counts as "MVC" or "MVP" or "MVVM" or the rest of the associated alphabet soup.

Suppose if I create a GUI application and I don't use the MCV/MVP pattern, but my code is clean, readable, and maintainable, is it still a code smell/bad design that I didn't use the MCV/MVP pattern?

Not at all, because MVC/MVP/etc are not right for every GUI application. For example, some GUIs might be so simple that it would be complete overkill, or some GUIs might not have any persistent state to put in a "model", etc. There are good reasons why that family of patterns is so popular, but they aren't the only ways to write good GUI software.

Also, a "code smell" usually means something about a specific snippet of code that might be a symptom of a larger problem. If all of your code is "clean, readable, and maintainable", without any exceptions, then almost by definition you don't have any code smells (except maybe a few "false positive" code smells that don't indicate any real problems).

So to answer the title of your question: "How to treat the MVC/MVP Pattern?", I would say: Go read about why those patterns are so popular, i.e. what problems they're trying to solve, so that in the future you can tell whether your latest problem might be solved by of those patterns.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy