How to handle some objects that cannot be categorized in object-oriented programming

This phenomenon will be encountered in all object-oriented projects, when we encode, for general objects such as MVC, we can put the written class file into the corresponding model view controllerBag inside. But for some common classes, such as some tool classes, or common objects, you can name a package for a class that seems a bit wasteful, but they don't really have anything to do with it.

It's a common practice to put it all into a similar util package, but I've recently seen an article saying that it's too simple and rude, and that other people don't understand the stratification, and I don't know how you deal with this problem.

Reply content:

This phenomenon will be encountered in all object-oriented projects, when we encode, for general objects such as MVC, we can put the written class file into the corresponding model view controller package. But for some common classes, such as some tool classes, or common objects, you can name a package for a class that seems a bit wasteful, but they don't really have anything to do with it.

It's a common practice to put it all into a similar util package, but I've recently seen an article saying that it's too simple and rude, and that other people don't understand the stratification, and I don't know how you deal with this problem.

There are no hard rules for this, and it is important that the code be formed within the team, and that each member of the team must adhere to the specification, thus reducing the familiar cost of joining the new member.

Some of the tool classes (like stringutils,collectionutils, etc.) that are common to the project within our team will also be util into packages, and for some common objects inside the module, if some enum classes are enums, they will be wrapped in a package; For example, Module1 and so on) the object between the inner layer and the layer, it will first name the package with a DTO, and then put it into a sub-package named after its module name, for some of the common objects between modules, put in common named child package, other common classes will be similar to the business function first named Package name, and then within the package Sub-packages are divided according to different modules.

Finally, it is important to form and follow the rules.

In theory "Object" should be composed of "state" (data) and "behavior" (logic), where state is a class member variable, and behavior is class member method.
The method of tools that the landlord says, in most static language, itself is non-object-oriented things, and how to organize in an object-oriented way? As an example of the Apache Commons Lang library commonly used in Java, the majority of these classes are composed of various static methods, such as StringUtils, and so on-the static method itself is pure logic, independent of the object, and does not hold state, Can say and usually we write programming language function almost identical, so this kind of method refer to Apache Commons Library or Java.util package write is good, also is the industry common practice.

But for the landlord mentioned this kind of tool method, here I would like to add, but also to the above paragraph "most static language" the attributive interpretation. If we put aside language restrictions and look at object-oriented, the existence of multi-tool methods is actually unreasonable.

Take a look at the tool class Java.util.Arrays class that comes with the JDK, and pick a method such as Arrays.sort (int[]) to sort the array of numbers:

public static void sort (int[] a);p ublic static void sort (int[] A, int fromIndex, int toindex);

The invocation of this method is:

int[] xx = Java.util.Arrays.sort (xx); Java.util.Arrays.sort (xx, 1, 10);

The way the static method above looks reasonable-because it is a sort of logic, but if it is written like this:

int[] xx = ... xx.sort (); Xx.sort (1, 10);

Isn't it more oo? I was going to sort the arrays, why not let the array sort itself? Look at the Org.apache.commons.StringUtils class and find a way to do it, for example:

public static Boolean Isalpha (Charsequence CS);

What do you prefer to write in the following call?

Org.apache.commons.StringUtils.isAlpha (astring);

Astring.isalpha ();

Does it remind you of "string". Trim () "string". IndexOf () These methods? If you want, you can turn all the methods in StringUtils into a string member method .... So instead of turning these things into a member method for the hairy JDK, let them exist in a static way in the ugly pure behavior class? This is actually caused by a variety of Java language features, such as:

1. a forced judgment on null . Makes String.isempty () somewhat chicken and stringutils.isempty (String s) exist reasonably
2. the existence of the primitive type . Makes the implementation of Int[].sort () impossible, and the behavior of int depends on the wrapper class integer.
3. objects are expanded in a single way . In order to maintain the refinement of the JDK, only limited methods can be provided on the string, and only static methods can be made because the string class cannot be extended.
4. 。。。

Look at other language situations:
1. The JavaScript language string does not provide a trim () method, but we can extend:

String.prototype.trim = function () {...} " String ". Trim ();

2. Object extensions in Objective-c can also use category in addition to inheritance (and the setting of nil in objective-c is grayed out in harmony)

@interface NSString (Cute)-(NSString *) Becute; @end ... [@ "string" becute];

Therefore, the answer to the landlord's question is: not these classes can not be categorized, but not a good class or language characteristics make it difficult to classify-only to be Utils tool class

Finally, more than 80% of A.method (b) that individuals have seen over the years can be changed into B.method () to be more oo. One of the most well-known and most widely recognized of all is:

Usermanager = ... Usermanagersingleton;usermanager.save (user);

Here is clearly the user's behavior (save) split into a separate Usermanager class to make a only behavior of a state is very strange, but also the completely stateless Usermanager instantiation of a singleton out, do an oo illusion to others to see ... Who are you kidding? Fortunately, Rod Johnson later admitted that spring's proposed notation was in fact a continuation of the EJB-era "transactional script", a anti-oo. Domestic technical environment impetuous, many people are learning from SSH, still think that they have been writing OO code, still think they understand oo ....

This is one of the reasons why I do not advocate purely object-oriented, many times it can be a function of the east, must be packaged into a class, plus a namespace, written as a static method.

If you use a better language system, you should first provide many important functions and classes in the language standard library.

followed by third-party libraries, as vendor

Then there is something of value in itself that can have common, or internal open source becomes a third-party library, canonical interface.

I do not advocate in a company a few projects between share common, otherwise the change of other team will bug/crash your product, instead of the original common fork out to modify.

And finally the code logic that is directly related to this project

Team communication is the most cost-effective, the only way to control the number of development teams

The key is your ability to organize your code and the ability to model your business logic. If your class name is right, can you describe the true business responsibility of this class? Your package name, class name should reflect your business logic, not simple model,controll,view, this name just reflects the architecture of the software, does not reflect your real business, I think should be avoided.

I think it is possible to think again between the controller and the model.

MVC is just a form of code, but don't be limited by MVC, a good level can be more than just MVC.
If the three layers in your business scenario are simple, such as "database takes down data, the controller is slightly processed, the view is displayed," then MVC is enough.
But if the data organization under the controller is quite complex, such as the need to operate many other systems, or a complex business process to get the final business data. There are still a lot of articles that can be done between controller and model.

That's how the code is organized between the controller and the model, which may be an annoyance after the initial adoption of an object-oriented approach, but it can be clear when you really understand the concept of object-oriented objects. Think you can refer to some of the "design patterns" of things.

You can set up many classes that are part of the service (wrapping many functions locally) or even encapsulate the more independent functionality into an internal API (HTTP server).

Object-oriented itself is a pit, not everything must be packaged with classes, such as functions, such as static methods, such as global objects? Does Java have to consider a single case so natural things why into Java is a pattern?

