"The time of maintenance on a project will increase in direct correlation to the number of steps between your View and your Model."
When estimating the amount of work required for any change to a system, you can estimate the time required to change the model or the view, and then multiply that time by the number of Degrees of Maintenance in the task to get a better estimation of the total time of the task.
Back Stories: MVC Concepts & Six Degrees
This theory assumes that you understand two other concepts first, the "Six Degrees of Separation" theory and the "Model, View, Controller" organization of software projects.
The "Six Degrees of Separation" theory days that everyone in the world is connected to everyone else by a maximum of six relationships. If you take any two random people anywhere in the world, and analyze their relationships, eventually you will find people they have in common, through friends, friends of friends, and friends of friends of friends.
The same idea of connectedness can be used with object-oriented software, to talk about the degrees of separation between objects, where inter-operating objects replace the concept of "friendships". I don't know if it can be said that the maximum number of degrees in software designs will also be six, but we can certainly think of objects as having degrees of separation from each other.
The Model, View, Controller theory organizes object-oriented code according to three behaviors. View code deals with display of information to a user. Model code deals with the storage of information for later retrieval. Everything else is a controller. There are several sub-categories of controllers, but if they don't touch views or data storage (models), they are controllers. These sub-categories include pre-processing and post-processing of information, either before or after display, or before or after data storage. And there can also be controllers which process information before or after other controllers.
The Points of Maintenance
MVC controller-to-controller action is what ads degrees of complexity to the maintenance of any software project. The more objects that the data passes through, from view to model, model to view, view to view, or model to model, the more potential points of bugs that can exist to corrupt that data before or reaches its destination. These are referred to as "Points of Maintenance".
The "Degrees of Maintenance Theory" says that with each introduction of a degree in the path that data travels, your time spent to modify code along that channel is multiplied. Therefore you should only add additional objects to the path with great caution, and weigh the benefits of pre- and post-processing against their cost of maintenance.
The Cost of Reusable Objects
This is actually the foundation of the design of "reusable objects". If an object can only be used to do pre- or post-processing of one other object, it's not a reusable object. The more other objects that a reusable object can interact with and perform its duties on, the more it tends towards creating an multiplying benefit that counter-balances the multiplicative Degree of Maintenance that it introduces at the same time.
Everything has a cost, and the Degrees of Maintenance Theory helps us to calculate the cost/benefit analysis between different object-oriented design choices, at the point of design, rather than later, at the point of maintenance, when usually it is too late to choose a different path.
I was called in to do maintenance on Java project once, which had the following layers:
- HTML & CSS Interface
- Java class which generated the HTML & CSS
- REST Controller
- Java Annotations for REST Controller
- View Controller Interface for REST Controller
- View Controller Implementation
- Post-Processing Controller for View Controller
- DAO (Data Access Object) Interface
- DAO Interface Implementation with SQL
Summary of Lessons Learned
Be very careful with what libraries you use, and how many you use. Do you really need a Front-End MVC implementation? It does keep your code better organized, but how much time is it saving you? Do you need a back-end MVC implementation? Maybe yes, maybe no. Does the time spent tracing your data through the extra layers, and debugging them, counter-balance the time saved by adding the library? Interfaces were designed for sharing implementation details between two or more objects. Don't create Interfaces unless you are actually going to be sharing those details. An Interface for a one-off object is a huge waste of time, code, and memory. Do you need a DAO? Not every project does.
Everytime you add a layer to your application code, think. Think about it as if you were looking backwards in time from some point in the future. Are you saving time now? How does that compare with the time you will save, or the time that you'll add to your project in the maintenance phase?