Shulou(Shulou.com)06/02 Report--

Code quality and output are the most direct criteria to measure whether a programmer is good or not. How to improve code quality and output? This should start with software refactoring and review. There are many books on refactoring and review on the market, but after reading it, the ability of the code can not be significantly improved immediately, it can only help us to solve the superficial bug and specification points, but can not help us to find deeper design problems.

Considering review from a design perspective, identifying bad code can effectively reduce technical debt. Technical debt refers to the debt caused by intentionally or unintentionally making wrong or non-optimal design decisions. With more and more debt, the problem can only be solved by thoroughly restructuring the project, which is also called technology bankruptcy. How to solve the problem of technical debt, it is necessary to make clear the important causes of technical debt-the bad smell of design and the lack of understanding of reconstruction.

First of all, it is necessary to clarify the principles of software design.

Abstract principle: simplify entities through simplification and generalization: simplification refers to the deletion of unnecessary details, and generalization is to identify and define important common features.

The principle of non-circular dependence: the relationship between packages cannot form a loop.

The principle of non-self-repetition: in detailed design, design entities and code and repetition may manifest as type name repetition and implementation repetition.

Encapsulation principle: the separation of concerns and information hiding are realized by hiding abstract implementation details and hiding changes.

Information hiding principle: identify difficult or potentially changing design decisions and create appropriate modules or types to hide these decisions from other modules or types.

Keep the principle of simplicity: simplicity is an important goal of software system design, and unnecessary complexity should be avoided.

Richter substitution principle: all subtypes must provide at least supertype committed behavior and references to each supertype can be replaced with subtype instances.

Hierarchical interface principle: use classification, generalization, substitution, sorting and other methods to organize abstractions in a hierarchical manner.

Modularization principle: create abstractions with high cohesion and low coupling through centralization and decomposition.

Opening and closing principle: the type should be open for extension and closed for modification. Specifically, the module should be able to support new requirements without modifying the code.

Single responsibility principle: there should never be more than one reason why a class needs to be modified, such as modifying a member may affect other irrelevant responsibilities of the class, making the class difficult to maintain.

Change encapsulation principle: advocate a way of information hiding, and suggest encapsulating concepts that may change. Many design patterns embody this design principle, such as strategy pattern, bridge pattern and observer pattern.

When we look at the code from a design point of view, we should follow six elements:

After understanding the design principles and six elements, let's look at the bad smell of design.

In this article, we only choose one of the bad smells for a specific explanation.

Abstract bad smell

Abstract principles advocate simplifying entities through simplification and generalization: simplification refers to the deletion of unnecessary details, while generalization refers to the identification and definition of important features. Traffic signs are abstract examples for communication, while digital symbols and programming languages are abstract examples for problem solving.

Lack of abstraction

This bad smell occurs when you use a series of data or encoded strings without creating a class or interface

Concept

One way to apply the principle of abstraction is to create an entity with clear conceptual boundaries and unique identity. Because an abstraction is not created to represent an entity, it is represented by raw data such as a basic data type or an encoded string, which violates the principle of abstraction and is called missing abstraction (Missing Abstraction). Unnecessary abstraction also violates the principle of modularity.

Latent cause

Unrepeated design analysis

Unreconstructed

Mistakenly focus on minor performance improvements

Example

In JDK1.0, the method printStackTrace () prints the stack trace to the standard error stream as a string.

In clients that need to programmatically access stack trace elements, you have to program code to get data, such as line numbers, and because customers rely on this string format, JDK designers can only be compatible with this format in subsequent releases.

Refactoring suggestion: the API of JAVA has been improved since Jdk1.4, and the StackTraceElement class is the missing object in the original design.

Alias

Base type paranoia: this bad smell occurs when you use the base type to encode the date and amount without creating a class.

Data mud: this bad smell occurs when colleagues use a series of data items in many places instead of creating classes.

Realistic consideration

Avoid overdesign: sometimes entities are just data elements without any associated behavior. In this case, using classes or interfaces to represent them can lead to overdesign.

Encapsulated bad smell

The encapsulation principle advocates the separation of attention and information hiding by hiding abstract implementation details and hiding changes. For example, do you have to know the principle of the engine when driving?

Inadequate encapsulation

For one or more abstract members, this bad smell occurs when the declared access exceeds the actual requirements. For example, a class that declares a field as public has a bad smell of "insufficient encapsulation".

Concept

The principle of encapsulation is to separate the interface from the implementation so that it can be modified independently. This separation of concerns allows clients to rely only on abstract interfaces and hide the concrete implementation from them. Modifying the implementation does not affect the client program. Inadequacies that are hidden within the abstraction are called Deficient Encapsulation.

Latent cause

For ease of testing

Adopt process thinking in object-oriented

Fast delivery

Example

Let's see that java.lang.System,in, out, and err are all declared as final, but values can be assigned through the setIn, setOut, and setErr of java.lang.System. Any code can easily use them, such as System.out.println ()

PrintStream exists in java 1.00.It only supports 8-bit ASCII values, and PrintWriter from Java1.1 supports Unicode. However, because applications can directly use PrintStream to access PrintStream methods, the PrintStream class can not be abandoned at all.

Refactoring suggestion: Java 1.6 introduces the java.io.Console class, which provides methods for accessing character-based consoles. Reader (), writer () to get the Console-related Writer and Reader objects.

Alias

Public properties, methods that can be hidden

Unencapsulated class

A class that contains unparameterized methods

Realistic consideration

Overly loose access in nested or anonymous classes

Performance considerations: such as java.lang.System mentioned earlier

Modular bad smell

The principle of modularization advocates the use of concentration and decomposition to create abstractions with high cohesion and low coupling.

Disassembled modularization

This bad smell occurs when data and methods that should be concentrated in one abstraction are scattered in multiple abstractions. It is shown that the class is used as a data container without any methods, and the methods of the class are more often called by the members of other classes.

Concept

An important approach to modular implementation is to "bring relevant data and methods together". If the abstraction contains only data members, and the method of manipulating these data members is located in other abstractions, it violates this implementation approach, and there is a bad smell of "fragmented modularization". It is called Broken Modularization.

Latent cause

Using object-oriented language with process thinking

Not familiar with existing design

Reconstruction suggestion

For the process design which contains a large number of data classes, the refactoring technique can be used to "transform the process design into objects".

Alias

A class that passively stores data

Data class

Data recording

Record class

Data container

Misplaced operation

Attachment complex

Misplaced control

Realistic consideration

Automatically generated code

Data transfer object

Hierarchical bad smell

The principle of hierarchical structure advocates the use of classification, merging, substitution and sorting to organize abstractions in a hierarchical manner. Such as the 8.7 million living things on earth.

Missing hierarchy

The code snippet uses conditional logic to explicitly manage behavior changes, and could have created a hierarchical directory and used it to encapsulate these changes, resulting in this bad smell

Concept

Type code-based switch statements (or concatenated if-else statements) are one of the most famous bad smells of design.

Using type codes to deal with behavior changes indicates that there is no meaningful classification, resulting in a lack of corresponding hierarchies in the design. It is called missing hierarchy (Missing Hierarchy).

Latent cause

Mistakenly adopt an overly simple design

Process design thinking

Ignoring the fact that inheritance is also a design technique.

Example

The concatenated if else statement shows the check types AbstractButton,JToolBar and JTextCompont and calls the method getMargin () under various conditions, which may occur elsewhere in the code in the future.

Reconstruction suggestion

If multiple implementations in conditional checking call the same method, relevant interfaces can be introduced to abstract the common protocol.

If your code contains conditional statements that can be converted to classes, you can use the refactoring technique "extract hierarchy" to create a class hierarchy, where each class represents a situation in the conditional check.

Alias

Tag class

Inheritance vacancy

Tight type hierarchy

Embedded function

Realistic consideration

Interact with the outside world

-dividing line-

I am Xiao Wei, focusing on micro-service technology sharing, and striving to explore more "high, refined and comprehensive" micro-service knowledge to share with you.

My Wechat: weiweiweiblack (Note: 51CTO)

Wechat official account: black Shaowei service, "share technology, love life", welcome to follow

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.