DESIGN: some suggestions and suggestions for beginners of Java design and development (1)

Scud (Flying Cloud Xia) http://www.jscud.com reprinted please note the author

In order to give some guidance on design issues to friends and colleagues, many points of view in this article are obtained from others' articles, and some points of view are certainly biased, some points are not discussed in detail. Please make more suggestions to correct them.

[Overview]
-------
At work, as a programmer or designer, you always need to design some function libraries or a framework. Of course, you need to do projects most often. Even a project will be changed frequently, or even give it to others for modification.
When you do this kind of work, all of your achievements should be made available to others, or for the convenience of others or for your own convenience, we should do our best to design well.
 

[Positive attitude, everything is constantly evolving]
----------------------------------

Technology is changing with each passing day. Every day, new technologies come out. The so-called "mountains and mountains, people outside the world". Every new wheel may be better than the wheel you want to design, therefore, when designing, You should know whether there are similar wheels and whether to design a new wheel.
Even if your wheel has been designed, it is hard to think that your wheel must be better than others, although your wheel may be more suitable for your actual use.
With the continuous development of technology, you and your friends/colleagues are constantly improving. "Let's take a look at things for three days", so do not think that your level must be higher than others, ", so do not be surprised, do not dislike your function library/framework, and do not think that others are" pick up ", maybe your function library/framework is not suitable for the current development.
 
 
Attitude determines everything. Your leadership may pay more attention to this.
 
 
[Necessary components: unit testing, documentation, instances, manuals, etc]
--------------------------------------------

Unit test, documentation, API doc, manual, Demo program, change log, README, build. XML, etc.

One day someone else used the function library/framework you designed. After you upgrade, the original project cannot work. After one day of debugging, you finally found the reason, an error was accidentally written.
You certainly don't want the above to happen, so please write a unit test. This will not waste your time or delay others' work. the time/pleasure you spend writing unit tests is certainly more valuable than the time and distress when you correct inexplicable errors after upgrading. are you not happy to see the green bar of unit test ?!
If you cannot guarantee that there are no mistakes in your program modifications, don't expect your colleagues to think that your mistakes are tolerable. They have long been jealous of you.
 
Take a look at any well-known framework that includes complete documentation, unit tests, sample programs, and user manuals. Please include these. oh, by the way, please write javadoc in detail. It is very important.
 
If a person using your framework/function library is looking for a method everywhere and looking for a class (but he does not know whether the class exists), it means that your document is not in place. if you want others to use your class or function, please write a document and do not expect others to read your source code to understand what it is.
 
If you do this, your function library/framework also has a "well-known" premise, isn't it? If not, I think it is impossible for others to use it better.
 
By the way, with these things, there is also a good directory organization. This can also be referred to the organization of other frameworks.
 
 
[Reference mature designs and existing projects]
--------------------------------

1. I have no idea about new things. Don't be surprised. I must first find an existing things to learn from.
 
Of course, the premise is not to re-invent the wheel, or you have sufficient conditions to re-invent a wheel.
Struts, webwork, spring, and so on are mature frameworks, no matter whether you use them in line with your habits.
Before you become a master, your design ideas are estimated to have been put forward and put into practice by our predecessors, so we must learn from them bravely. "standing on the shoulders of giants" we can take a closer step.
 
For example, we get tired of using the following code when accessing the database:

Try { // Your code here } Catch (exception E) { // Catch exception } Finally { // Must do something }

We can refer to the jdbctemplate class of the Spring framework to see how it uses the callback function for processing.
 
If we use the above Code when using hibernate, refer to the hibernatetemplate of Spring framework.
 
It is also a shortcut for reference.
 
Warning: do not copy documents. Use the code to indicate the source, and respect others.
 
 
2. In actual projects, you can often refer to existing projects for your own design.
 
For example, if I do not know how to access the database, how to layout, and how to layer a website, we can refer to the existing website programs to see how others use sitemesh or tiles layout, how to Use hibernate to access the database or use the encapsulated JDBC class to access the database, and how to use struts, webwork, or other access layers.


[Follow the Conventions] 
-------------------------

To make it easier for others to use your things, follow the common practices when designing some common functions or classes, and do not make any difference unless your internal implementations are indeed different.

For example, to implement a class similar to arraylist, do not write it like this:

Public int count () { Return list. Size (); } Public item getitem (int I) { Return list. Get (I ); }

 
This should be the case:

Public int size () { Return list. Size (); } Public item get (int I) { Return list. Get (I ); }

 
 
Of course, everyone has their own ideas. If you think that your original method is better than the ordinary one, please provide two ways for others to choose. it will not cause you any trouble. It is only an easy-to-understand method, so you don't have to worry about it. It is advantageous to do so.
 
Many classes have some common design practices. when you design a new class, let's take a look at the JDK source code/documentation to see how others implement it. this helps to promote your achievements.
 

 

[Do not be superstitious about Authority] 
---------------

When using an existing framework or function library, do not think that everything is correct or the best, certainly not. there are no perfect things. The existing things must have an unreasonable design or an overly idealistic design for the present because of various limitations or the level of the author, but cannot meet the actual situation.
 
Not superstitious authority can reach a new realm.
 

[Do not reject them easily. If you do not understand them, do not give your opinion rashly. be rigorous]
------------------------------------------------

It is often seen on the Internet. net and Java, or struts vs webwork, or others. it is often seen that one party does not know much about the other party's things, and then starts to criticize it. Instead, it is ridiculed if it fails to say its ideas.
The comparison between several technologies is sometimes necessary, for example, when selecting a technology. But if some people who do not know the technology at all choose to make a selection, can you be convinced of the result?
Existence is reasonable. Any technology has its own reasons. Although some things have long expired, they came into being at the time.
Several technologies are used to solve the same problem, but there are also many problems. There are also many ways to solve them. Everyone has different ideas and different ideas, therefore, there are no absolutely qualified technologies, but they should meet your technical requirements. so do not exclude other things easily.
 
If you do not understand the technical comparison, do not give your opinion easily. At least you can understand it yourself. It is better to express your opinion after practice.
 
When posting comments, you must be rigorous. Do not draw conclusions easily. You must go through proof. Otherwise, an error will only make your opponent joke and make your colleagues look down on you. for example, if you say that hibernate3 does not support jdk1.3, you 'd better find your evidence. Otherwise, it will become a mistake. (hibernate3 supports jdk1.3)
 
As a technician, rigor should be one of our habits, whether in development or design.