It's easy to get started with a piece of code

Preface

Today, I accidentally saw a framework with a description like this:

Xxx does not want others to directly modify the code of the YYY framework, because XXX is committed to making it perfect. The code written by others has no significance. However, you can serve as a mouse, provide comments, raise bugs, and I am willing to accept good idea.

Here, I will explain that xxx is the name of the author, and YYY is the name of the framework. As a result, there are many cool people on the OSC, so I want to learn at the speed. In fact, if the framework is good or not, you can see one or two by looking for the sample code. I found the sample code and picked two methods:

/*** Publish an article ** @ return */public Object add () {Request r = Context. get (Statics. REQUEST); String title = r. get ("title"); String desc = r. get ("desc"); String content = r. get ("content"); String cats = r. get ("cats"); String pic = r. get ("pic"); String keywords = r. get ("keywords"); List <String> l = new ArrayList <String> (); String [] cs = cats. split (","); for (String s: cs) {s = s. trim (); if (! S. equals ("") {l. add (s) ;}} Validator. check (title, new RuleNotEmpty ("title"); HttpSession session = r. find (WebExecute. TAG_SESSION); User user = (User) session. getAttribute (Global. SESSION_USER); ITrans t = TransFactory. getTrans (); String id = ID. next () + ""; IInserter ins = t. getInserter (). table ("T_ARTICLE"); ins. set ("C_ID", id); ins. set ("C_TITLE", title); ins. set ("C_DESC", desc); ins. set ("C_USER_ID", user. g EtId (); ins. set ("C_CONTENT", content); ins. set ("C_TIME", Dater. ymdhms (Dater. now (); ins. set ("C_DAY", Dater. ymd (Dater. now (); ins. set ("C_PIC", pic); ins. set ("C_KEYWORDS", keywords); ins. insert (); if (l. size ()> 0) {for (String cat: l) {t. getInserter (). table ("T_ARTICLE_CAT "). set ("C_ID", ID. next ()). set ("C_ARTICLE_ID", id ). set ("C_CAT_ID", cat ). insert () ;}} else {t. getInserter (). table ("T_ARTICLE_CAT "). set ("C_ID" , ID. next ()). set ("C_ARTICLE_ID", id ). set ("C_CAT_ID", 1 ). insert ();} t. commit (); t. close (); return new Tip ("published successfully");}/*** modify article ** @ return */public Object modify () {Request r = Context. get (Statics. REQUEST); long id = r. getLong ("id"); String title = r. get ("title"); String desc = r. get ("desc"); String content = r. get ("content"); String cats = r. get ("cats"); String pic = r. get ("pic"); String keywords = R. get ("keywords"); List <String> l = new ArrayList <String> (); String [] cs = cats. split (","); for (String s: cs) {s = s. trim (); if (! S. equals ("") {l. add (s) ;}} Validator. check (title, new RuleNotEmpty ("title"); HttpSession session = r. find (WebExecute. TAG_SESSION); User user = (User) session. getAttribute (Global. SESSION_USER); Logger. getLog (). info (desc); ITrans t = TransFactory. getTrans (); IUpdater iup = t. getUpdater (). table ("T_ARTICLE"); iup. where ("C_ID", id); iup. set ("C_TITLE", title); iup. set ("C_DESC", desc); iup. set ("C_USER_ID", user. getId (); iup. set ("C_CONTENT", content); iup. set ("C_PIC", pic); iup. set ("C_KEYWORDS", keywords); iup. update (); t. getDeleter (). table ("T_ARTICLE_CAT "). where ("C_ARTICLE_ID", id ). delete (); if (l. size ()> 0) {for (String cat: l) {t. getInserter (). table ("T_ARTICLE_CAT "). set ("C_ID", ID. next ()). set ("C_ARTICLE_ID", id ). set ("C_CAT_ID", cat ). insert () ;}} else {t. getInserter (). table ("T_ARTICLE_CAT "). set ("C_ID", ID. next ()). set ("C_ARTICLE_ID", id ). set ("C_CAT_ID", 1 ). insert ();} t. commit (); t. close (); return new Tip ("modified successfully ");}

Today, I posted a method in a famous group. As a result, some people said, "isn't it clear? I think it's good ."

At that time, I was busy and didn't have time to give a detailed description. So I decided to take time to explain the analysis at night. I couldn't ensure that all of them were correct, and I couldn't guarantee that they could all be accepted, however, it will certainly help you think about some framework development issues:

1. What is a framework?
2. What issues should we consider during design?
3. How is a passing framework?

Answers to Questions

The above three questions are raised. The three questions are complex and difficult to explain. They are not clear in three days and two days. They are simple and easy to explain.

What is a framework?In fact, many people do not understand this issue.

The essence of frameworks and libraries is:

• The framework considers mechanism reuse, while the library mainly considers code reuse.
• The framework considers extension without changing the mechanism, while the library does not consider expansion issues.
• The framework itself is incomplete. In most cases, it cannot do anything on its own, while the database itself is complete and can solve problems in a certain field.
• The framework is live. Through continuous expansion and derivation, it becomes more powerful, and the database is dead. What is it like when it is released.

Of course, there are many perspectives on the comparison between the two products, but I personally think the essence is what I mentioned above.

What issues should be considered during design?The answer to this question, if you use one sentence to describe the symbol, is: you should carefully consider the feelings of people using this framework, and consider how to make users feel better. Of course, if it is unclear in three days or two days, we have to explain the methodology, problem fields, and design principles.

How is a passing framework?This problem is explained in one sentence, that is, if the previous problem is met without violating the basic design principles, it can be regarded as a passing framework. If we use three days and two days to describe, we need to take out all the basic design principles, clarify them one by one, and clarify them one by one.

If the first condition is met, the user is satisfied, and the use is good; if the second condition is met, the design and implementation are good. If both of them meet the requirements, it means that at least a passing framework is available and, of course, more points may be scored.

Code analysis

Okay, I have mentioned some of the issues that should be taken into account in the framework design process. Let's take the above code into consideration. I admit, I didn't see the specific implementation in the framework. All the "conclusions" below are actually my judgments or guesses. If there is anything wrong, please correct me:

1. These two methods seem so similar, but they are not very harmonious.
2. Context seems to be a static class, indicating that it must have something like ThreadLocal for some data storage. If ThreadLocal is used, there are still a lot of things to pay attention, this method is not recommended for individuals.
3. Data acquisition: The request object is used to directly read the value. Of course, we can see that the request author has encapsulated the value, but obviously, developers will be very disgusted with this.
4. Transaction processing: all the processes are written in the code. Well, if all the services are written in one method, it is OK. If not, this is troublesome.
5. Data validation: This method also creates validation objects for verification, so we can see that the same code is used in both methods to do the same thing.
6. Exception handling: I didn't see any exception handling content, so I don't know what the foreground will see if an exception occurs when the table to be operated is not saved. Is it a bunch of exception stacks?
7. Function declaration: the input and output parameters cannot be seen from the Declaration of the function. Therefore, it is determined that all processing requests must be obtained from the context, session. The returned value is an Object. What does this mean? It indicates that type conversion should be performed in Jsp display.
8. Code duplication: because transactions are written in methods, it means that these methods cannot be reused, and many codes must be written repeatedly.
9. Processing capability expansion: Because database processing and business presentation are put together, it indicates a typical B/S architecture. That is to say, the processing capability is very easy to estimate, in addition, the capability of horizontal scaling is relatively limited. It also indicates that the system is relatively weak in security (the database and application server are on the same layer. If the application server is broken, there will be reverse database behavior)
10. Transaction object: I have a question: why do I need to execute a t. close statement in t. commit? If a commit exception occurs, is it close? If no close is found, how can this problem be solved?

Next, let's take a look at the points that violate some common symptom object design principles:

Single principle: too many things are done in a method. How tired will this code be when it is changed?

Abstract principle: there is no independent Dao and Pojo, and the Dao layer and business layer are not stripped, which leads to repeated data verification and cannot be reused. You can think about it. If you want to enable the adding and modifying functions provided by these two methods to provide external services through Json or WebService, the only feasible way for programmers is to write two more methods.

DRY principle: do not repeat the work. There are too many duplicates in the code. This may be simply to illustrate the meaning or be casual.

Automatic principle: if the program can be automatically completed, do not let the programmer manually complete it.

Summary

Not all of the content summarized in the two codes is correct. If there are any errors, welcome Haihan and criticize and correct them.

In fact, the reason for analyzing these two pieces of code is approved by the Author. As a result, these two sections of code are typical and can be met but cannot be obtained. In addition, I also hope that the code author can do things in a high profile, keep a low profile and make a framework that someone else cannot optimize and improve.

It's easy to get started with a piece of code