Further decoupling using static libraries

Question

I've been thinking for a while about reasons that prevent a lot of programmers — myself first of all — from writing clean, modular and expressive code while developing, for example, CocoaTouch apps.

What I discovered is that my top-three of reasons are following:

1. UI code. Device-specific UI/UX, general clutter, 'quick fixes and workarounds' and so on.
2. Poor Controller-View decoupling. Sometimes Controller ends up doing job that the View is responsible for.
3. Sparse test harness.

Of course, those problems stem from lack of discipline or habit to write clean code. But it is difficult to discipline yourself if the environment allows you not to do that.

It is easy to sort laundry if you have a set of dedicated drawers, but if you have one drawer, it will slowly turn into mess — unless you are very disciplined.

And then I tried to apply that idea of 'sorting drawers' to address my code problems — and I thought that it is possible to sort MVP components as follows:

1. Model is actually a framework of classes responsible for dealing with data. Model is reusable, as it is a set of routines to work with data.
2. View is actually a framework of classes responsible for presenting information graphically. It doesn't depend that much on environment and it definitely can be reused.
3. Controller is a framework of classes responsible for coordination of aforementioned layers and working with user interaction paths. Application itself is something like (?) a big controller. Since it glues together a defined set of models to a defined set of views, it is not reusable and depends heavily on those + platform etc.

So given the M and V are somewhat reusable, and C is not — maybe it makes sense to force separation of M and V? The best way to ensure they are separated is to put them in static libraries. After that they can be linked to the app, which contains only controller code.

This approach seems to me quite good because:

• only controller depends on something here
• developer can write separate test suites for those modules
• user interface classes can be reused in other apps easily
• model classes can be extracted to cross-platform codebase while maintaining the old facade
• commits are limited to three really distinct modules — what's more distinct than a separate library?

What do you think? Does this sound like an idea to follow?

Answer 1

MVC is an old and well used pattern that started with desktop apps. It can sort-of sometimes apply to web-apps as well. People have done well even when they somewhat misapplied this pattern (e.g. to a web app), so I can't discourage you there.

One thing to consider as an alternative is a service. Google Steve Yegge's Service Rant. I think it's titled somethings like "Why Amazon is better than Google." If you have a good front-end coder on the team, you can basically leave the View on the client/browser. Then you need to define a set of data view and update calls between client and server. I'm assuming, of course, that you have a central server. Maybe use JSON to communicate. Then your back-end just does security/authentication (who can view or update what data) and basically translates canned queries into JSON and vice-versa. Any finer-grained interaction can happen entirely on the client, which saves bandwidth and simplifies both client and server code at the same time by removing dependencies and providing a more sensible separation of concerns.

Now, if your app happens entirely on one device, maybe MVC is all you need. Just providing another perspective for your consideration.