3

If I write an application and decide to develop only a single graphical interface for it, and never intend to develop multiple GUIs, then by today's standards it is okay not to use the MVC pattern or MVP pattern, or should you generally prefer the MVC pattern for object-oriented software with output? The advantage of the MVC pattern is precisely that of being able to program many different GUIs. However, if you plan to develop only a single GUI from the start, this advantage will be eliminated.

  • 3
    " The advantage of the MVC pattern is precisely that of being able to program many different GUI's. " That is an advantage, but hardly the reason why people use MVC. – Polygnome Feb 3 '18 at 22:41
8

The advantage of being able to program to many different GUI's is minimized if you only have one GUI. But understand that you have multiple GUI's if you ever update your GUI.

The point of decoupling isn't simply ability to work with multiple components. It's that that the other components can change without impacting the rest of the system. So if you're looking for a situation where you can disregard these advantages you need a better excuse than your magical ability to predict that there will never be "multiple GUI's". You need to also predict that the one you make will never need to change.

You certainly can do this. I know I've written plenty of "untestable" throw away code before. Just own up to what you're doing.

  • 1
    I always found your answers regarding OO insightful. This is the first time I don't agree with you. "Decoupling" in the sense of publishing data out of the object destroys encapsulation (and incidentally actually increases coupling!). I agree with the poster that this should be not done without deliberation. In fact I think it should be only done as a last resort. Or do you mean something different by "MVC" or "Decoupling"? – Robert Bräutigam Feb 3 '18 at 19:12
  • @RobertBräutigam Well thank you. I must admit I'm confused. When did I endorse publishing without regard for encapsulation? – candied_orange Feb 3 '18 at 19:18
  • 1
    I didn't get your complaint either, Robert. Candied is pointing out to the fact that decoupling has nothing to do with 1 server - n clients. Has to do with resilience (tolerance to change). On the other hand, there's nothing wrong publishing data out of the components (no matter in which level of abstraction they live at). The problem is publishing implementation details. That's what causes coupling. – Laiv Feb 3 '18 at 19:36
  • @CandiedOrange You implied to endorse MVC, and most MVC interpretations today are based on anemic objects. You didn't elaborate what you meant exactly, that is why I asked! Sorry if I misunderstood you. – Robert Bräutigam Feb 3 '18 at 20:45
  • @Laiv Data is an implementation detail in OO, so you are sort-of contradicting yourself. – Robert Bräutigam Feb 3 '18 at 20:47
6

The primary point of MVC and related architectures is to structure the flow of data and behaviour in your application. In particular, we want to separate the presentation of data from internal representation and business logic because that makes it easier to work on the GUI or on the business logic. There may be other benefits (such as reusing business logic, or better testability), but those are secondary.

In some small cases you will be fine without these patterns. But for a more complicated program, you will need a clear architecture to avoid a “big ball of mud”. MVC/MVP/MVVM are a few popular choices for that architecture. Decoupling the external interfaces from internal logic is such a great idea, it's even used outside of GUIs.

3

First, I applaud your approach to consider the trade-offs, even for things that seem dogmatically part of our thinking nowadays.

Short answer: Yes, absolutely, if you know what you are going to do, there is absolutely no reason to artificially separate things that naturally belong together. Like objects and their representation on the UI.

Long answer: Depends on what you mean by MVC. If you mean the usual meaning nowadays, to have a pure data structure ("Model") that some procedures ("Controller") shovels back and forth, then these will definitely not help you. In fact, this will make your application significantly harder to maintain, since any modification in the actual "business" object will exponentially propagate through these structures.

However, doing everything in the objects would be also wrong. The objects should have just enough display functionality to not have to allow external objects access to their internal data, but not as much to have to deal with irrelevant details like color, font-size, things like that.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.