Step-by-step development of Object-oriented Thinking

 

After I step into the software industry, I have been suffering from no guidance from my predecessors. I am always confused by two questions: first, how to cultivate the Thinking Ability of object-oriented design? 2. Is there any way to design the architecture?

Since I have been working on projects for so many years, I seldom see the code written with beautiful Object-oriented thinking. I feel it is necessary to remind young practitioners. Now I want to summarize my experiences and hope to inspire my new friends.

 

My basic idea is that object-oriented thinking can be developed step by step. In layman's terms, we are constantly coding practices. Quantitative changes will lead to qualitative changes.

1. Insufficient motivation for developers

I remember that the first project after I joined the work was the Operation Support System Development of a telecommunications Bureau. The development framework used was a combination of struts1 + EJB + Hibernate and weblogic8 as the application server.

In the twinkling of an eye, ten years of time passed away and gradually adapted to the life of the middle-aged uncle.

Interestingly, classic combinations are not outdated so far (never be so outdated), especially in enterprise applications, such as SSH combinations: struts/springmvc + spring/EJB + hibernate/mybatis/JPA and so on.

The emergence of open-source frameworks can greatly reduce the development workload as long as secondary development is carried out on its basis. As long as senior engineers build the project development project, junior developers can develop business functions according to the template Code, based on Huludao and pipeline jobs.

From the perspective of the overall production efficiency of the project team, this is indeed a great improvement. Each member has a different division of labor. They can do part of their work well and comply with the modern enterprise management philosophy. However, from an individual perspective, it has also caused some disadvantages. For junior developers, he is a screw engineer with a long assembly line and has no chance to think about how to implement object-oriented design.

Here I use a common user login module as an example. The system uses a classic layer-3 architecture for layering. The class diagram is as follows:

 

Briefly explain the business scenarios:

1) The user accesses the system logon page in a browser, enters the user name and password, and submits the form.

2) The system verifies the user name and password, and records user access logs for further auditing. The user password information stored in the database is an encrypted string.

 

As a beginner developer, to develop business functions, you often only need to copy and paste the six classes in the graph. Sometimes even the passwordencoder class is omitted. In addition, some project teams have developed their own code generation tools, and even the copy and paste operations are omitted. They only need to make a few modifications to the code generated by the tool to complete the development.

 

Back to the class diagram, is it necessary to define the loginservice and userdao interfaces here? Copy, paste, and code generation tools make the workload low, and junior developers do not have the motivation to think about this problem. They can complete the functions based on Huludao and close the job.

 

My personal idea is whether it is necessary to depend on the specific project requirements and the division of labor.

1) if the business module is completed by one developer and the system does not need to support multiple databases, that is, the userdao interface can be removed without multiple implementation classes. At the same time, if the system only passes database query authentication, and loginservice does not have multiple implementation classes, it can also be removed.

2) if each layer of the module in the project team is divided by different personnel, the interface is introduced to enable the previous layer to start development earlier due to the dependency between layers, it also makes unit tests at the previous layer easy. In this case, the loginservice and userdao interfaces are reasonable.

3) in projects, some modules must have multiple implementation classes because of service layer and Dao layer. From the perspective of code style consistency, it is tolerable that a class corresponds to an interface. This is to maintain the readability of the code and objectively reserve the scalability of the system.

Generally, the loginservice and userdao interfaces are reasonable.

 

These development frameworks encapsulate a lot of common functions, and their source code contains a lot of good ideas. The addition, deletion, modification, and query of a single form can not reflect the value of good because of the simple business requirements. To a certain extent, this allows developers to think about the power of good.

For example, for the separation of controllers and views in the MVC Architecture, the conversion of business model classes and Servlet APIS is complicated and requires the Ood abstraction capability. The framework has already been implemented for you. The framework is much easier for developers. For example, in spring, Java Bean creation and management, dependency injection, declarative transactions and log processing based on the interceptor and dynamic proxy mechanisms, there are also complex points such as integration support with other frameworks, which are all implemented for you. In addition, it is also complicated to convert the Entity objects in hibernate to tables in relational databases, translate API calls into SQL statements, support for various database syntaxes, and cache query results.

Conversely, if you don't need any framework, You can implement a medium-scale web application. Check that the code you write is not much different from the code currently developed based on the framework. I think self-implementation may not be better designed than the open-source experts, but I can fully understand where the difficulties are and whether Ood has application scenarios, this is because the writing process hurts. Although programming is easy, oo is not easy, and compilation and cherish.

2. Object-oriented examples in the Java platform

In the Java API specification, it can be said that Ood is everywhere. Here, we only use two examples of Servlet and JDBC specifications. Different vendors implement servlet APIs at the underlying layer and implement JDBC drivers, completely blocking developers, both sets of specifications implement refined abstraction.

The servlet API encapsulates the request information in the HTTP protocol into an httpservletrequest object, and the response message is encapsulated into an httpservletresponse object. Developers can directly obtain various HTTP header information and parameter information in HTTP Communication from these two objects, and complete the response information output to the HTTP client.

JDBC APIs allow developers to use the same APIs to interact with databases without considering specific database types.

It can be said that the servlet API has mastered Java Web Application Development; The jdbc api has mastered Java database application development.

The Java open-source community provides a large number of excellent frameworks, such as Lucene, hadoop, hbase, Mina, netty, and activemq, which are widely used in the Internet and e-commerce industries. (It seems that you will not be able to find a job in Java at half past one, but when you are young, you are young and energetic. I suggest you do iOS development simply and rudely without explaining it ).

3. Object-oriented is not applicable to all business scenarios

In Java, everything is an object. Can all business problems be designed and implemented in an object-oriented manner? You need to know that ", ", Ood is not a universal universe truth!

For example, to implement a factorial of a natural integer n. You can't abstract the problem of object-oriented thinking. In this scenario, procedural implementation is simpler and more straightforward. There are also many mathematical derivation formulas.

For another example, the project has a need to implement the shortest path algorithm. Although I wrote 10 classes in the object-oriented way of thinking to implement the function. One search on the Internet, and one or two classes implemented by the C language using the storage of the adjacent matrix are implemented. The object-oriented approach may be more suitable for developers to understand. for computers, process-oriented implementation may be more efficient.

In my opinion, the essence of computer technology is computing. Data in various binary formats is transmitted through network communication, and then the system stores the computing results or returns the results to the caller over the network.

Our thinking style cannot be exclusive and does not include other design concepts. I think it's a bit silly to beat good in the world. This is actually quite difficult. We were educated from an early age by the same concept, political correctness, and even the same value. We cannot have any objection. You can often see peer-to-peer confrontation on the forum. Fortunately, with the openness of the Internet, more and more people have diversified world views and values.

 

4. Learning design patterns helps you understand OOD

The design pattern lists the best practices for some classic business scenarios and is worth learning. We learned 23 common tricks in the design model to cultivate our understanding of Ood.

As if we were reading martial arts novels in which all the 18 martial arts tricks were learned, it was not worth the effort of 9 Yang. For the master of internal strength, flying sand Walking stone leaves can hurt people's lives.

But at the beginning of learning martial arts, zhaza and practicing weapon boxing are still helpful to cultivate understanding.

At the same time, it cannot be applied to the model. I think it is exquisite and I want to always use the model everywhere. For example, due to the lack of education, it is just like in the age of students that boys are enlightened by watching love action movies in the island country, if you imitate the hero and practice every trick in every scenario, some difficult actions will not be completed and hurt yourself, you know.

The essence of the design pattern is to follow the open and closed principle, extract common code to the parent class, and abstract the variable behavior into an interface for encapsulation. The refinement of models should be a matter of course.

As long as you develop interface-oriented programming, it depends on abstraction rather than specific implementation classes. When the practical experience of coding reaches a certain critical point, quantitative changes lead to qualitative changes, and you may find that the written code is already using the design pattern. Everyone has heard that 10 thousand hours of theory, proficient in a skill often requires more than 10 thousand hours of practice. If you have been programming for more than five years, even if you don't have high-profile guidance, you will have an epiphany on Ood.

5. Continuous reconstruction can help cultivate abstract thinking

The essence of good is abstraction, abstraction, and abstraction. However, everyone has an accumulation of design experience, and it is impossible to design very well at the beginning to meet all the needs of the project.

Abstract thinking abilities require a gradual process of cultivation. We constantly learn the source code of excellent open-source frameworks, and the learning design model is an external means to force our brains to learn abstract ways of thinking.

The problem domain is a sub-system and a module. abstract thinking fosters the ability of object-oriented design, system analysis, and Domain Modeling. If the problem domain is the whole system or multiple systems, the system architecture design capability is cultivated.

People who have some practical programming experience have had this experience. If there are repeated code segments in the system, 2 ~ Three times, it will be disgusting, especially a large segment of code with hundreds of lines of almost the same. Because each person's coding experience is different, the design may not be in place during development. Can we refine and reuse it?

The answer is yes, because we have the refactor magic weapon.

Continuous Refactoring can effectively improve the object-oriented design. I often look at other people's code and unconsciously help with refactoring. This is just a habit. Of course, we must rebuild it step by step while respecting the original author.

The difficulty lies in the naming of classes and methods, the division of duties of classes, and the granularity of abstraction. These are really only based on experience, understanding and understanding, there is no certain standard, what is good, what is not good. I think the naming should at least be clear and easy to understand. The class should have specific responsibilities and the method length should not be too long. For details, refer to the reconstructed scriptures written by Daniel Martin.

 

Finally, a person's understanding of knowledge is not linear growth or parabolic rise. It should be a step ladder. Each step requires an irregular accumulation period, and the internal awakening caused by external factors can continue to the next step. Things that were previously hard to understand may be relieved as they grow older. I heard that there was a succession, but eventually I had an epiphany.