Sometimes some things can be written in a class can also be multiple classes, how to balance various constraints, find a suitable balance point?
For example, Python's own cgi.escape and Htmlparser.htmlparser, mixed with the Pascal nomenclature does not say, the two features such encapsulation is for what consideration?
Reply content:
It's easy to write unittest and never destroy the package.
The first is methodology:
- A method based on use cases analysis
- Based on the CRC method (ClassResponsibility collaborator)
Second, understand the principle of object-oriented
- Abstract principles
- Follow the principle of cohesion, low coupling
- Adhere to the solid principle, especially the open and closed principle (open/closed principle) and the single responsibility principle (mono responsibility principle)
Finally, continue to refactor the experience of experience.
In the early stage of demand analysis, the needs and functions are carefully divided. Then, divide the function into several piles. A bunch of functions focus on doing a certain kind of thing, such as database reading, database writing, interface interaction, data calculation, etc.
You see, the natural is not out of the "class" this thing.
When designing, focus on two aspects.
First, the interface must be isolated. Solid mentions the two principles of single duty, interface isolation. A single duty is really hard, and sometimes it's more cost-effective to break it. But interface isolation must be done. Interface is not isolated, it is impossible to single duty, it is difficult to observe the opening and closing, the Richter principle.
Second, consider the opening and closing principle. The opening and closing principle is the core idea of all software design. But it's too hard to be strict. First of all, no one can take into account all possible changes in the beginning, and second, even if considered, the cost of implementation will remain high. Therefore, in the acceptable workload range, you and the business, the demand side of the experience to do some open and close design on the line.
Development, mainly by experience and skills to do some refactoring.
One thing you can mention here is that some code specifications that seem boring are sometimes really helpful. For example, a method cannot exceed 30 rows, and a class cannot exceed 300 rows. When the number of rows exceeds the norm, you will naturally want to refactor and dismantle the molecular class.
In addition @vczh said to UnitTest, this is also a good idea, especially in the practice of TDD. In the case of an entity, an object of the same set of attributes can be classified as a class, even if there is a class, if multiple classes share a set of attributes, the common attribute group is classified as an inheriting class, and then the concrete class inherits the subclass and then implements the difference.
If all can be classified into a class and can be divided into multiple classes, should not handle the public properties. This question has to be discussed separately.
For the change of the demand is not frequent, of course, test whether the convenience of the basis.
As for the frequent changes in demand, believe me, as long as can run on the line.
So I've always been working as hard as possible with the business logic layer, and I've always struggled to write core functions. For example, for a typical back-end MVC project, I typically write M, at most, write a bit of interface between M and C. But the main parts of C and V I don't want to move at all. This time, I finished writing my interface can be a good test-based writing class. Purely by feeling ... This is why we need design patterns. Want to refer to GoF (
"Design patterns:elements of reusable object-oriented software").
=============================
Well, I don't have much experience in large-scale projects, or see the above answer the main answer. SOLID (single function, open/close principle, Richter replacement, interface isolation, and dependency inversion) according to the business,
If you think from the perspective of the object,
is to encapsulate the concept,
Concepts can be divided into objects,
Behavior and State,
Of course
There are others who think of it as a complete concept,
Can also be divided out,
Individually depicted,
It's kind of like painting. class to encapsulate the changes. It is easy to encapsulate where the requirements change, which also corresponds to the opening and closing principle of the design pattern (open for derivation, closed for modification).
