N-Tier Development with Model-View-Presenter and Testability (Part 1)
N-Tier Development with Model-View-Presenter and Testability Series
Part 1 - Intro
Part 2 - Tiers Overview and Business Tiers
Part 3 - User Interface Tiers
A lot has been said about testability and why it´s so important to unit test your code, but do we really organize our projects towards achieving maximum testability (more about measuring testability of an application later) without crippling our teams’ productivity? I believe most of the time we don´t, or at least not until we follow a very strict discipline. Following a standard is not so hard to accomplish if you do understand the reasons behind the standard. I´m not trying to set a standard here and by no means I believe that this is a “one-size fits all” pattern. I´ll just try to illustrate some experience that I´ve gained from the 10 years that I´ve been developing enterprise applications.
Most of the time the team that is developing the project knows the business domain, or at least the lead dev knows, but that´s not enough to assure that the project meets the determined quality levels agreed with the customer (even if sometimes it´s an internal customer). The keyword here is “assure”, since we must have ways to guarantee that the product is working without having to resort to an enormous staff of testers. The testers are very important to make sure that the product meets the functionality as described in the technical specifications. The dev team must have mechanisms to secure that a change request will not break any existing functionality, and that mechanism is Unit Testing.
Another very common topic is coupling versus cohesion. Everyone wants to reduce coupling and increase cohesion, but very few really understand why these matter so much.
Cohesion
In computer programming, cohesion is a measure of how well the lines of source code within a module work together to provide a specific piece of functionality. Cohesion is an ordinal type of measurement and is usually expressed as "high cohesion" or "low cohesion" when being discussed.
Modules with high cohesion tend to be preferable because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability whereas low cohesion is associated with undesirable traits such as being difficult to maintain, difficult to test, difficult to reuse, and even difficult to understand.
Cohesion is expressed in seven levels from the worst to the best:
Coincidental cohesion (worst)
Coincidental cohesion is when parts of a module are grouped arbitrarily (at random); the parts have no significant relationship (e.g. a module of frequently used functions).
Logical cohesion
Logical cohesion is when parts of a module are grouped because they logically are categorized to do the same thing, even if they are different by nature (e.g. grouping all I/O handling routines).
Temporal cohesion
Temporal cohesion is when parts of a module are grouped by when they are processed - the parts are processed at a particular time in program execution (e.g. a function which is called after catching an exception which closes open files, creates an error log, and notifies the user).
Procedural cohesion
Procedural cohesion is when parts of a module are grouped because they always follow a certain sequence of execution (e.g. a function which checks file permissions and then opens the file).
Communicational cohesion
Communicational cohesion is when parts of a module are grouped because they operate on the same data (e.g. a module which operates on one the same record of information).
Sequential cohesion
Sequential cohesion is when parts of a module are grouped because the output from one part is the input to another part like an assembly line (e.g. a function which reads data from a file and processes the data).
Functional cohesion (best)
Functional cohesion is when parts of a module are grouped because they all contribute to a single well-defined task of the module (e.g. calculating the sine of an angle).
(Adapted from the Wikipedia article at http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29)
So we can see why having high cohesion is so important. It makes our code more readable, easier to maintain and easier to test. So if we are to stay with testability in mind we are sure to struggle to achieve the highest level of cohesion we can, and that reflects on what tiers we´ll be using and the way they interact. Now let´s take a look at why it´s a very good idea to keep coupling at the lowest level possible.
Coupling
In computer science, coupling or dependency is the degree to which each program module relies on each one of the other modules.
Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.
Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong"). Low coupling refers to a relationship in which one module interacts with another module through a stable interface and does not need to be concerned with the other module's internal implementation (see Information Hiding). With low coupling, a change in one module will not require a change in the implementation of another module. Low coupling is often a sign of a well-structured computer system, and when combined with high cohesion, supports the general goals of high readability and maintainability.
Systems that do not exhibit low coupling might experience the following developmental difficulties:
· Changes in one module force a ripple of changes in other module.
· Modules are difficult to understand in isolation.
· Modules are difficult to reuse or test because dependent modules must be included.
Specifically, coupling increases between two classes A and B if:
· A has an attribute that refers to (is of type) B.
· A calls on services of an object B.
· A has a method which references B (via return type or parameter).
· A is a subclass of (or implements) class B.
Low coupling may also reduce performance, and a highly-coupled system is sometimes desirable to achieve maximum efficiency. Regardless, in many modern computing systems, the cost of reduced performance is often seen as a worthy trade for the benefits to the software development process that result from low coupling.
Coupling is expressed in seven levels from the worst to the best:
Message coupling (low and best)
This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange messages.
Data coupling
Data coupling is when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data which are shared (e.g. passing an integer to a function which computes a square root).
Stamp coupling (Data-structured coupling)
Stamp coupling is when modules share a composite data structure and use only a part of it, possibly a different part (e.g. passing a whole record to a function which only needs one field of it).
This may lead to changing the way a module reads a record because a field which the module doesn't need has been modified.
Control coupling
Control coupling is one module controlling the logic of another, by passing it information on what to do (e.g. passing a what-to-do flag).
External coupling
External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface.
Common coupling
Common coupling is when two modules share the same global data (e.g. a global variable).
Changing the shared resource implies changing all the modules using it.
Content coupling (worst)
Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module).
(Adapted from the Wikipedia article at http://en.wikipedia.org/wiki/Coupling_%28computer_science%29)
Since we must achieve maximum testability without making our project hard to maintain we´ll also keep in mind that we must make our tiers the less coupled possible, even if we can´t achieve Message-level coupling.
Well, this is rapidly becoming a very large post, so I´ll leave an initial explanation on the tiers to the next post.
#98