My answer is:. "Coding itself is a design, you can design your code."
In fact, as the outline design and detailed design, system design and architecture as design, coding and design is no clear boundary, each correct growth of the programmer, must begin coding, and slowly exercise abstract thinking, logical thinking, object-oriented thinking and then slowly transition to the system design, and then with experience and knowledge, and slowly transition to architectural design. Now I will be in a recent coding tasks at hand, briefly explain how to "design" your code.
The task is such that a client of a bank payment system receives the transfer data bank entered by the user, when the transfer data is approved by the state shifts to the "transfer", while the client need JMS asynchronous manner to the payment system background sends a message with the transfer records (Instruction), the rear end after receiving the information, in accordance with some relevant information needed Instruction first determined transfer this data is sent directly to the real transfer funds clearing (clearing) banking system, or stay in the back-end system, wait workflow (work flow) you need to perform back-end systems. The back-end systems need to have two workflow Instruction execution, but needs to be selected according to some of the relevant information Instruction.
In order to simplify the complexity, I assumed here that the system has a InstructionHandleMsgDrivenBean, which has a bean onMessage () method, need to implement all the business logic in the process.
At the same time explain the detailed operational details:
- Instruction needs to determine whether to stay in the rear end waiting to perform the specified workflow has three conditions: xx, yy, zz, when three conditions are true, stay.
- Analyzing Instruction A process or need to take the process B is determined by a combination of four factors, if the representative true with "Y", "N" on behalf of false, then the elements consisting of the four "XXXX", a total of 16 combinations, different the combination of a and B, respectively, down processes, such as: YYNN, YYNY to a, NNYY, NNNY to B, ...... not cumbersome.
void the onMessage public (InstructionInfo instructionInfo) {
IF (XX && && YY ZZ) {// wait for staying at the rear end for performing the specified workflow
// conditional judgment according to each composition, which process down
if (a == true && b to true to true && == C == D == to true && {
...
}
the else IF (...) {...}
the else IF (...) {...}
...
the else (... ) {...} } }
This approach is most developers welcome, because it is simple, direct, but also precisely this approach reflects the common problem of developers - use Java to write code purely process-oriented.
Well, said a lot, how to "design" your code? The answer is: the use of object-oriented thinking:
After we get the demand can be analyzed, this requirement is generally divided into two parts:
- Determine the need to stay in the back-end part of waiting to execute the specified workflow
- Choose which part of the workflow to go
With this premise, I can design a single object the two responsibilities:
public class InstructionHandleDecisionMaker {
public static boolean isHandledByBackEnd(InstructionInfo info) {
return (isXX(...) && isYY(...) && isZZ(...));
}
private booolean isXX(...) {
//TODO Implement the logic
return false;
}
private booolean isYY(...) {
//TODO Implement the logic
return false;
}
private booolean isZZ(...) {
//TODO Implement the logic
return false;
}
}
public class InstructionWorkFlowSelector {
private static Map mapping = new HashMap();
static {
mapping.input("YYNN",WorkFlow.A);
mapping.input("NNYY",WorkFlow.B);
...
}
public static WorkFlow getWorkFlow(Instruction info) {
StringBuilder result = new StringBuilder();
result.append(isA(...)).append(isB(...));
result.append(isC(...)).append(isD(...));
return mapping.get(result.toString());
}
private static String isA(...) {
//TODO Implment the logic
return "N";
}
private static String isB(...) {
//TODO Implment the logic
return "N";
}
private static String isC(...) {
//TODO Implment the logic
return "N";
}
private static String isD(...) {
//TODO Implment the logic
return "N";
}
}
You can see, I press a class segregation of duties, responsibilities and press to extract the private methods, "the framework of" good design, in order to let the compiler, I filled out the above complete code, then add TODO identity, then, I can I write the onMessage method:
public void onMessage(InstructionInfo instructionInfo) {
if( InstructionHandleDecisionMaker.isHandledByBackEnd(...) ) {
WorkFlow wf =InstructionWorkFlowSelector.getWorkFlow(...);
//TODO Implment the logic
}
}
So far, I've been thinking a pure object-oriented "design" Well my code, and then, my thinking is very clear, and therefore the code structure is very clear, single responsibility, high cohesion, low coupling, and finally, I can (not described) to write my implementation details of the demand, according to the document slowly.
Things are always complicated by the composition of some of the more simple things, but these things also by the simple things simpler composition, and so on. Therefore, when writing code, to the complex problem into object-oriented thinking, and then further broken down, and finally destroyed one simple question, this is one design. Developers as long as the habit, even if you are just doing the bottom of the coding work every day, in fact, you have been involved in the design work, with the accumulation of knowledge and experience, slowly, you start from the design code, up to design classes, methods, and then is the design module, and then design subsystem, and then design the system ...... in the end, step by step to become a good architect.
Finally, there is a dedication to the truth impetuous programmer:
Excellent architects, designers, programmers must be good, because you do not post up, give up coding.
Additional information: This blog is purely discusses a habit of thinking, not to its rote practice, regardless of the actual situation, do so directly in coding time, not necessarily the best choice. In the actual coding, you must consider the following questions:
- You need to consider the reusability of the business logic and complexity, the need to design a new class or method to extract a new private packing logic, encoded or directly (if simple enough) on the original method.
- The new business logic, whether or not already exist in some places, can be reused, even if does not exist, this logic should be encapsulated into a new class, or should be placed into an existing category, which requires a clear division of responsibilities.
- We need to make trade-offs in design and performance.
- If you add new features in existing systems, and coding style shelf system with a far cry from what you want, but you do not have enough time to carry out reconstruction costs, you should let your code and ready-made system remains consistent style.
Reproduced in: https: //www.cnblogs.com/softwareking/archive/2011/03/29/1999258.html