Occasionally, you write classes that only contain static methods and static fields. This kind of reputation is not very good, because some people abuse them to avoid object-oriented programming, but it does have their usefulness. We can use java. lang. math or java. util. arrays, which is used to organize the basic type or array-related methods. [java] public class Arrays {public static void fill (long [] a, long val) {...}} you can also use jva. util. collections, which organizes static methods (including static factory methods) in objects that implement specific interfaces; [java] public class Collections {public static <T> boolean replaceAll (List <T> list, T oldVal, T newVal ){...}} finally, this type can be used to organize methods in the final class to replace the extension of the final class. This tool class is not designed to instantiate it, and its instances are meaningless. However, if you do not explicitly compile the constructor, the compiler will provide a common default constructor without parameters. This constructor is no different from other constructor methods. We often see this kind of casual and instantiated class in released APIs. It is not feasible to force the class to be instantiated by defining the class as an abstract class. Classes can be divided into subcategories, while subclasses can be instantiated. In addition, this will mislead the user that one class is designed to inherit (Item17 ). However, a simple usage ensures that the class cannot be instantiated. The compiler generates default constructor only when no explicit constructor exists in the class. Therefore, as long as the class contains a private constructor, it cannot be instantiated: [java] www.2cto.com // Noninstantiable utility class public class UtilityClass {// Suppress default constructor for noninstantiability private UtilityClass () {throw new AssertionError ();}} because the explicit constructor is private, this method cannot be accessed outside the class. AssertionError is not necessary, but it ensures that the method will not be accidentally called within the class, and it ensures that the class will not be instantiated under any circumstances. This kind of habit is a bit intuitive, because constructor has been provided but cannot be called. Therefore, the clever way is to add a comment, as shown in the preceding example. The side effect of this kind of habit is that the category cannot be quilt. All constructors of the Child class must call the parent class constructor implicitly or explicitly. In this case, the Child class has no accessible parent class constructor to call.