Classes

Class Organization

Following the standard Java convention.

package com.gpcoder;

import java.time.LocalDate;
import java.time.LocalDateTime;

/**
 * Class documentation comment...
 */
public class ClassOrganization {

    /**
     * Class ( static) variables
     */
    public static String PUBLIC_STATIC_VAR = "";
    protected static String PROTECTED_STATIC_VAR = "";
    static String DEFAULT_STATIC_VAR = "";
    private static String PRIVATE_STATIC_VAR = "";

    /**
     * Instance variables
     */
    public String publicStaticVar = "";
    protected String protectedStaticVar = "";
    String defaultStaticVar = "";
    private String privateStaticVar = "";

    /**
     * Constructors
     */
    public ClassOrganization() {
    }

    /**
     * Methods
     * <p>
     * These methods should be grouped by functionality rather than by scope or accessibility.
     * For example, a private class method can be in between two public instance methods.
     * The goal is to make reading and understanding the code easier.
     */
    public void doSomething1() {
        task1();
        task2();
    }

    private void task1() {
    }

    private void task2() {
    }

    public void doSomething2() {
        task3();
    }

    private void task3() {
    }
}

Refer to: https://www.oracle.com/java/technologies/javase/codeconventions-fileorganization.html

Encapsulation

We like to keep our variables and utility functions private, but we’re not fanatic about it. Sometimes we need to make a variable or utility function protected so that it can be accessed by a test.

Classes Should Be Small!

The first rule of classes is that they should be small. The second rule of classes is that they should be smaller than that.

The name of a class should describe what responsibilities it fulfills. In fact, naming is probably the first way of helping determine class size. If we cannot derive a concise name for a class, then it’s likely too large. The more ambiguous the class name, the more likely it has too many responsibilities. For example, class names including weasel words like Processor or Manager or Super often hint at unfortunate aggregation of responsibilities.

public final class CommonUtils {

    private CommonUtils() {
    }

    public static String toJson() {
    }

    public static <T> T fromJson(String json, Class<T> tClass) {
    }

    public static String toJson(Object obj) {
    }

    public static String concat(String delimiter, String... str) {
    }

    public static boolean isNotBlank(String str) {
    }

    public static <T> List<T> subList(List<T> list, int start, int numberOfElement) {
    }

    public static String randomString(int length) {
    }
}
public final class JsonUtils {

    private JsonUtils() {
    }

    public static String toJson() {
    }

    public static <T> T fromJson(String json, Class<T> tClass) {
    }

    public static String toJson(Object obj) {
    }
}

public final class StringUtils {

    private StringUtils() {
    }
    
    public static String concat(String delimiter, String... str) {
    }

    public static boolean isNotBlank(String str) {
    }
}

public final class CollectionUtils {

    private CommonUtils() {
    }

    public static <T> List<T> subList(List<T> list, int start, int numberOfElement) {
    }
}

public final class RandomUtils {

    private RandomUtils() {
    }

    public static String randomString(int length) {
    }
}

We should also be able to write a brief description of the class in about 25 words, without using the words “if,” “and,” “or,” or “but.”

Avoid God class

God class—or, alternatively, god object—is an anti-pattern that consists of having a class that does too much. A god class is usually a huge class that concentrates a lot of responsibilities, controls and oversees many different objects, and effectively does everything in the application.

There are several problems with God Class:

  • Violate SOLID

  • Make Your Code Fragile

  • Harm Testability

  • Harm Performance

  • Make the Code Harder to Understand

The Single Responsibility Principle

The Single Responsibility Principle (SRP) states that a class or module should have one, and only one reason to change. This principle gives us both a definition of responsibility and guidelines for class size. Classes should have one responsibility—one reason to change.

Refer to SRP - Single Responsibility Principle for details.

Cohesion

Classes should be cohesive — cohesion results in many small classes.

Classes should have a small number of instance variables. The more variables a method manipulates the more cohesive that method is to its class. Try to separate the variables and methods into many small classes such that the classes are more cohesive.

There are 2 types of Cohesions: Low Cohesion and High Cohesion.

Refer to Coupling and Cohesion for details.

Follow principles & patterns

PreviousFunctionsNextComments

Last updated