Robert C.Martin wrote an interesting article about a set of metrics that can be used to measure the quality of an object-oriented design in terms of the interdependence between the subsystems of that design.
Here’s from the article what he said about the interdependence between modules:
What is it that makes a design rigid, fragile and difficult to reuse. It is the interdependence of the subsystems within that design. A design is rigid if it cannot be easily changed. Such rigidity is due to the fact that a single change to heavily interdependent software begins a cascade of changes in dependent modules. When the extent of that cascade of change cannot be predicted by the designers or maintainers the impact of the change cannot be estimated. This makes the cost of the change impossible to estimate. Managers, faced with such unpredictability, become reluctant to authorize changes. Thus the design becomes rigid.
Relational database management systems are the most commonly used system to store and use data, but for extremely large amounts of data, this kind of system doesn’t scale up properly.
The concept of “NoSQL”(Not Only SQL) has been spreading due to the growing demand for relational database alternatives. The biggest motivation behind NoSQL is scalability. NoSQL solutions can offer a way to store and use extremely large amounts of data, but with less overhead, less work, better performance, and less downtime.
There is a powerful and simple concept in programming that is really underused: Immutability.
Basically, an object is immutable if its state doesn’t change once the object has been created. Consequently, a class is immutable if its instances are immutable.
There is one killer argument for using immutable objects: It dramatically simplifies concurrent programming. Think about it, why does writing proper multithreaded programming is a hard task? Because it is hard to synchronize threads accesses to resources (objects or others OS things). Why it is hard to synchronize these accesses? Because it is hard to guarantee that there won’t be race conditions between the multiple write accesses and read accesses done by multiple threads on multiple objects. What if there are no more write accesses? In other words, what if the state of the objects threads are accessing, doesn’t change? There is no more need for synchronization!
Java 6 was released in 2006 and Java 7 in 2011. No major changes were added to the Java7, many of the new features were present in Java 6 updates. After Java 7 Oracle has decided to implement a two years roadmap planning for Java, and the next major release will be available in 2013.
Java 8 has some interesting new features like lambda expressions, but the major new feature planned was Jigsaw, in fact Jigsaw was originally intended for Java 7 but was deferred to Java 8 and now it’s moved to Java 9.
Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa.
Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability.
The goal of this case study is to show the benefits of low coupling and high cohesion, and how it can be implemented with Java. The case study consists of designing an application that accesses a file in order to get data, processes it, and prints the result to an output file.
Solution without design: