DEV Community: Tin Trinh

Write effective code for equals method

Tin Trinh — Wed, 02 Sep 2020 00:51:31 +0000

Why do we need to override the equals method

Q: When to override the equals method?
A: If the class not override it and the object identity is merely not enough for equality.

A right implementation of equals makes the instance object to serve as map keys or set elements with predictable and desirable behavior

equals method is characteristic:

reflexive: an object should equal itself.
symmetric: if object A equals object B, object B should equal with object A as well
transitive: if A equals B, B equals C, so A should equal C.
consistency: the same result will return no matter how many times you run it.

And one more important characteristic that only exists in the OOP world.
Lisov substitution principle says that any important property of a type should also hold for all its subtypes so that any method written for the type should work equally well on its subtypes.
What does that mean?
For example:

class A {
   int size;
}

class B extends A {
    Color color;
}

A a = new A(1);
B b = new B(1, Color.RED);

a.equals(b) // should return true

Extend instantiable class and add a value component to it violate the transitive rule easily.
Like java.util.Timstamp extend from java.util.Date and add nanoseconds field.

One common mistake this that do the null checking and getClass() to compare in the equal method. That will make the equals method not able to have the Lisov substitution characteristic.

Not necessary to null checking in the equals method. Simply cast it to the object we want so we could have the accessor to it.

public boolean equals(Object o) {
  if (!(o instanceof MyType)) {
      return false;
  }
}

Conclusion

High quality equals method:

Use the == operator to check if the argument is a reference to this object: Performance optimization
Use instanceof to check if the arg has the correct type. No need to do the null check.
Cast argument to correct type.
Check if a file of the arg matches the corresponding field: if float or double field we need to call Float.compare and Double.compare the method, if the field is object filed call the equals method recursively. To avoid the possibility of NullPointerException, using Objects.equals(Object, Object)

After writing the equals method.
Is it symmetric? Is it transitive? Is it consistent?

Use the AutoValue framework to write hashCode and equals more easily.

Effective Java: #7 Obsolete object and memory leak

Tin Trinh — Sun, 02 Aug 2020 07:47:54 +0000

Java is the Garbage Collector programing language. What does that mean to you?

I mean that the language will take care of cleaning the unused objects in your program. If you come from a language like C/C++ you will feel that this is like a superpower because you don't have to manually clear the memory for the objects that you don't use anymore (the task that the developer keeps forgetting a lot).

Java did the magic through its Garbage Collection algorithm. There are a lot of them currently but basically it will check for the reference of the currently executed program with the objects that exist in the heap. If there is any object that wasn't referenced by the program, it will clear those objects as it considers those objects as garbage.

Let's consider this example, that I took from the book:

class PoolObjects {
   private static int DEFAULT_POOL_SIZE = 100;
   private int size = 0;
   private static Object[] pools;

   public PoolsObjects() {
      this.pools  = new Object[DEFAULT_POOL_SIZE];
   }

   public void add(Object o) {
      this.ensurePoolSize();
      this.pools[this.size++] = o;
   }

   public Object pop() {
      if (this.size == 0) {
         throw new EmptyPoolException();
      }
      Object r = this.pools[--size];
      return r;
   }

   private void ensurePoolCapacity() {
      if (this.pools.length = this.size) {
         this.pools = Arrays.copyOf(this.pools, 2 * size + 1);
   }
}

In the above example, there is a leaking memory point that is very subtle. As you can reason, as we decrease the size of the array, the element that has an index less than the size value will be inactive or should be discarded and clear by the GC. But actually it won't be because that object still gets referred by the pools variable.

One way to fix the problem is nulling out the element that hasn't been referred anymore.

public Object pop() {
      if (this.size == 0) {
         throw new EmptyPoolException();
      }
      Object r = this.pools[--size];
      this.pools[size] = null; // Explicitly nulling out the element at size index.
      return r;
   }

I would like to conclude the blog with some commonplace that memory leak could happen.

The application that manages the memory by itself. The example above
The application that uses caches. The object cached could stay in the memory forever.
The listener or callback that registers but not dis-register.

Effective Java Part 5 - Prefer dependency injection to hardwiring resource

Tin Trinh — Tue, 30 Jun 2020 14:22:24 +0000

There are a ton of situations that you need to create an object that depends on the other objects. In those situations, using Singleton or static class is not appropriate.

It's better to have the class constructor to allow to pass in the resource that needs to parameterized the constructed object instead of using setter to change its behavior that may cause the class hard to test and maintain as well as hard to track its status transformation.

When writing the constructor, let's think about what we really depend on when we create the object. And pass those dependencies in the object is somewhat called dependency injection.

Nowadays, there are lots of framework help to do dependency injection easily so we don't have to do it manually. But the idea of them is the same. By showing the interface of what we depend on in the constructor and satisfy those dependencies when initiating them.

Effective Java Part 4 - Enforce noninstantiability with a private constructor

Tin Trinh — Thu, 25 Jun 2020 15:38:34 +0000

When to use this?
When you want to create a class to hold bunch of static fields or static method. And you don't want to create any instance of the class.

To prevent making object from class we could mark the class as abstract but this would make the class looks like it mean to be inherited by other subclass and those subclass could be instantiated.

So the best way to enforce the noninstantiability is create an private constructor for the class.

class A {
    private A() {}
}

Even better but not strictly required, an exception could be throw if the constructor will be called setting would help to prevent unexpected call to the constructor from inside of the class

class A {
    private A() {
        throw new AssertError();
    }
}

Effective Java Part3 - Singleton

Tin Trinh — Thu, 25 Jun 2020 15:26:27 +0000

Singleton in Java is a concept that describes that a class should have one and only one of the instantiated object. What does that mean? With one class there is no different object initiated.

There is some way to implement that.
First, we can use the static public instance filed in class.
For example

class A {
    public static final A INSTANCE = new A();
    private A() {}
}

With the static final filed, we make a very clear statement about the class

The second way to implement a Singleton is by using the static factory method.

class A {
    private static A INSTANCE = new A();
    public static A getInstance() {
        return INSTANCE;
    }
    private A() {}
}

By using this static factory method we could have some advantage over using the public static instance field.
We could change not using Singleton anymore without changing the API of the class. We could also return the class that is a subtype of the return class.

Effective Java Programing Part 2 - Creating and destroying objects.

Tin Trinh — Thu, 25 Jun 2020 00:45:10 +0000

Consider the static factory methods over the constructors

One advantage of using factory methods over the constructors is that the factory method has a name. If the parameters that passed into the constructor is not helping to understand what object will be returned to the client code.

The factory method with a well-chosen name will help the client code easier to read.

The second advantage of using a factory method over the constructor is that it doesn't have to return a new object every time it was invoked. So this method is very helpful when we trying to create an object that will be used a lot or expensive to create. And that class will be called instance-controlled. Because the class controls the creation of its class. Those classes could be Singleton or Non-Instantiable. It allows immutable class can guarantee that no two equal instances exist. a.equal(b) if and only if a == b

The third advantage is that it could return any subtype of its return type. This will be a good practice to return an interface as return type and has the implementation-specific class hidden.

With Java 8, the interface could have the static method. I didn't know about that or how that could help me to do anything? Why would I need a static method for an interface?

In the case of JDBC, Connection plays the part of the service interface, DriverManager.registerDriver is the provider registration API, DriverManager.getConnection is the service access API, and Driver is the service provider interface.

Effective Java Programming Part1 - Some thoughts about effective programming

Tin Trinh — Wed, 24 Jun 2020 18:51:10 +0000

First rule first, code should be reused instead of copying.

Learning the art of programing is like other disciplines, consist of learning the rule and then learning when to break them with good reason.

@Bean and @Component. What is the different? Which one should use be used?

Tin Trinh — Sat, 23 May 2020 05:24:06 +0000

The most benefit of using a framework like Spring is auto-configuration. By only introducing the library or the module to the classpath, Spring could automatically scan it and create the necessary object and @Autowrired it.

@Component is an annotation that annotates a class. It tells Spring to use this class to create a bean if there is somewhere else depend on this class. The creation of the class is totally controlled by Spring. And only one bean created per class.

@Component
class UserService {
    public void updateUser(User user) {
    …
    }
}

@Controller
class UserController {
    private final UserService userService;

    @Autowired
    public UserController(UserService userService) {
        this.userService = userService;
    }
}

In this example, Spring will recognize the appearance of the UserSerivce class because it was marked with @Component annotation. So when it tries to initiate the UserController object, it knows that it needs a UserService to put to UserController constructor. And the creation of the UserService will be controlled totally by Spring. It is a pretty declarative way to define dependency.

With @Component our life is so good. So why do we even need something like @Bean annotation? When should we use it? First, @Bean is an annotation that used for annotating the function (not a class) that will return an object of a class that will be registered as a bean object by Spring.

You could use it in case you are using a third-party library when you don’t have access to the source code of the library. So you can’t just put @Component annotation of the class that you to create a bean.
You can combine with the @Configuration annotated the class that contains the method return the beans or otherwise Spring won’t catch and register it as a bean for your dependency resolution.
Let’s consider this example.

class UserService {
    private final PasswordEncoder encoder;

    @Autowired
    public UserService(PasswordEncoder encoder) {     
            this.encoder = encoder;
    }

    public String createUser(UserCreateReq req) {
        UserEntity user = UserEntity.builder()
                            .setPassword(this.encoder.encode(req.getPassword()))
                            …
                            .build();
        repo.save(user);
    }
} 

@Configuration
class PasswordEncoderConfiguration {
    @Bean
    public PasswordEncoder bCryptPasswordEncoder() {
        return new BCryptPasswordEncoder();
    }
}

In this example, I couldn’t change the code base of the bcrypt library so to create the encoder object. I have to use a @Configuration class to create the bean that I need in a method inside that @Configuration class. In this way, we could create as many as you want bean objects. And you have to explicitly configure those bean by yourself when the conflict happens. One way to resolve that conflict is by using the @Qualifier annotation in the constructor of the dependent class.

That's all. Happy coding.