Art of Object Design on MPDay

Last sunday, I gave a speaking as a speaker in the msup open day conference in ShangHai. My topic was Art of Object Design, mainly focused on low level design in the software development lifecycle. I want to dig the essence of software design deeply. As we know, there are amount of principles and patterns for software achitecting and design. It is impossible to grasp all of these. You know more, understand less. Through by analyzing the essence and core idea of design patterns and architecture patterns, I summarized seven principles including Reusability, Extensibility, Separation, Change, Simplicity, Consistency, Indirection.

   

Reusability

The most evil enemy in the software development is repeat. It results in developing repeaded so that we cann't reuse some components and functions effeciency. It would generate the bad smell of solution sprawl. How to avoid repeat? We must keep the objects to be fine-grained and high cohesion. It needs to use encapsulation reasonable.  We can improve the reusability of software based on three-level: method, class and module. For instance, we can extract method or super class, define some helper class, devide modules by dependency.  The following diagram demonstrates how to apply template method pattern to reuse some codes in JUnit Framework:

Extensibility

The excellence structure of software should be extensible so that we can add functions without modifying the source code. There are two meaning of extensibility. First we don't add new features to expose it, that is an extensiblity internal.  We can decorate the target object or control it by providing a proxy object. Second is an extensiblity external. The inheritance and composition are the common approach. Of course, we don't forget the abstraction. For example, the Runnable interface in Java supports the extensiblity of business when you want to write the multi-thread program.

class MyThreadStart implements Runnable {
     public void run()  {
        //do something
    }
}

Thread controller = new Thread(new ThreadStart());
controller.start();

Separation

Concern separation is the most important principle for architecting architecture. The classic patterns which embody the concern separtion are layered architecture pattern and MVC pattern. The key element of separtion is that seperating changeful resposiblity from changeless object. That is core value of SRP also. Of course, we must focus on the collaboration between objects too. The following diagrams list my opinon about separation: 

Change

One of the inevitable thing is change in the software development. So we must find the change point when we analyze the requirement. In my experience, I think these points always are changed as below:

1. Business Rule (Solution: Specification Pattern)

2. Algorithm and Strategy (Solution: Strategy Pattern)

3. Command and Request (Solution: Command Pattern)

4. Hardware Environment (Solution: Abstraction Layer or Gateway Pattern)

5. Protocol and Standard (Solution: Metadata)

6. Data Schema (Solutioin: Encapsulate Data or Information Hide)

7. Business Flow (Solution: Customize Workflow)

8. System Configuration (Solution: Metadata or Database)

9. User Interface and Presentation (Solution: Layered Pattern, MVC Pattern)

10. External Services (Solution: Abstraction Layer or Service Facade)

Simplicity

There are two important principles we have always to keep in mind. These are KISS(Keep it simple and stupid) and YAGNI(You aren't gonna need it). How to simplify the complex implemention? We can use encapsulation to hide the complex implementation. The abstraction is the other way. It might unify model, and elimilate the difference. As architect, most of them want to pursue the perfect solution. It's wrong! Many anti-patterns related with this idea, such as Analysis Paralysis, Accidental Complexity.

Consistency

So called "Consistency" includes interface, format, invoking way and solution. If we have consistant interface, so the implementation can be substituted. If we have consistant format, we can infer the overall design from the part of design. Consistant invoking way would help client understand the intention of service provider. Consistant solution is the basic of cooperation of team. For example, we can achieve the consistant invoking way by using composit pattern:

 Indirection

David Wheeler said:"All problems in computer science can be solved by another level of indirection". Indirection in software programming is achieved by delegation, abstraction and collaboration. Indirection can reduce dependence, hide the detail and simplify the client call. Many pattens are reflect the indirection thought, such as Facade Pattern, Mediator Pattern, Adapter Pattern, Strategy Pattern, Service Locator Pattern.

Scalability Principles

One of the most important aspects which should be considered about during you design the architecture of system is scalability. In the future, the requirement will be changed, the system will overload, the amount of user will be increased. If you don’t consider about the scalability of software system, you system is becoming rubbish.

Several days ago, InfoQ posted the useful article wrote by Simon, it was Scalability Principles. This article presented some principles and guidelines for building scalable software systems.

To build scalable software systems, you should try your best to decrease processing time. Thus the system can handle more user requests in the same amount of time. The article gave some strategies to achieve this goal.
* Collocation: reduce any overheads associated with fetching data required for a piece of work, by collocating the data and the code.
* Caching: if the data and the code can’t be collocated, cache the data to reduce the overhead of fetching it over and over again.
* Pooling: reduce the overhead associated with using expensive resources by pooling them.
* Parallelization: decrease the time taken to complete a unit of work by decomposing the problem and parallelizing the individual steps.
* Partitioning: concentrate related processing as close together as possible, by partitioning the code and collocating related partitions.
* Remoting: reduce the amount of time spent accessing remote services by, for example, making the interfaces more coarse-grained. Please consider the first law of distributed computing - don’t distribute your objects.

Scalability is inherently about concurrency. As Martin Fowler said in Patterns of Enterprise Application Architecture, concurrency is one of the most tricky aspects of software development. Whenever you have multiple processes or threads manipulating the same data, you run into concurrency problems. To handle the concurrency issue is very difficult, you have to consider many aspects, e.g. lock, resource contention, deadlock, concurrent transaction, etc. This article presented some simple principles that can help when building scalable systems.
* If you do need to hold locks (e.g. local objects, database objects, etc), try to hold them for as little time as possible.
* Try to minimize contention of shared resources and try to take any contention off of the critical processing path (e.g. by scheduling work asynchronously).
* Any design for concurrency needs to be done up-front, so that it’s well understood which resources can be shared safely and where potential scalability bottleneck will be.

In order to build a successful software system, you need to know what your goals and what you’re aiming for. Your design must meet not only the functional requirements, but also non-functional ones. Non-functional requirements include performance, security, scalability, interoperability etc. Before you build the software system, you need to know related information about non-functional requirements as early as possible.

You must keep test continuously in order to satisfy the non-functional qualities of a system.

Probably the most important principle for building scalable system is that, if you need your system to exhibit this characteristic, you have to design it in up front. Even you fulfill RUP or Agile methodologies, it is necessary still. At least, you should outline the overall view of the system architecture.