When you’re trying to come up with a software architecture, you’re typically trying to define an ontology of objects. What do objects give us? Code reuse. Therefore any software architecture you create must take into consideration the future changes that are likely to occur. It’s difficult to foresee what problems will come up, which is where experience helps a lot. But when writing the actual code you must always ask yourself “If I write the code this way, will I be able to reuse this code without touching its internals?”
I’ve seen people pay lip service to architectures such as MVC but it’s quite clear when reading the code that they don’t understand that all MVC is really trying to do is allow you to separate the presentation and control logic from the actual data.
Another important aspect of this question is having single source data. For example, in a database you wouldn’t usually want to store a value in two different places where there’s a constraint that the two values must be the same, because if you change one, there’s a potential for a programmer to make a mistake and not change the other.
0 Responses to “Evaluating Object Oriented Designs”