Notes on "Elegant Objects (Volume 1)" - continued

Notes from Chapter 3 - Do not use Static Methods!

Expose Fewer Than Five Public Methods

So, I 'm suggesting you use the number of public and protected methods as a primary metric of class size. The number I have in mind is 5. So why 5? There 's no particular reason; it 's just how I feel. If there are fewer than five public methods in a class, that is acceptable. IF there are more, the class needs refactoring. Something is wrong with it.
My Notes
That is how I feel.. What a solid reasoning.

I guess it is nice to "try to" keep a class small. But how would you keep this Interface small?
import biz.tugay.sakila.core.model.BaseModelObject;
import javax.persistence.EntityManager;
import java.util.Collection;
import java.util.List;
 
public interface BaseDao<Entity extends BaseModelObject> {
    EntityManager entityManager();
    Entity get(EntityManager entityManager, int id);
    List<Entity> getAll(EntityManager entityManager);
    void beginTransaction(EntityManager entityManager);
    void insertNew(EntityManager entityManager, Entity entity);
    void commit(EntityManager entityManager);
    void rollback(EntityManager entityManager);
    void flush(EntityManager entityManager);
    void close(EntityManager entityManager);
    void insertMultiple(EntityManager entityManager, Collection<Entity> actors);
    void remove(EntityManager entityManager, Entity e);
    void update(EntityManager entityManager, Entity e);
}
I think this Interface is fine as it is.. Refactoring this class, just to expose less than 5 public methods? I can not imagine how it could be done, or how it would be helpful. So, good advise, but not a very strict one I guess..

Don 't Use Static Methods

The use of static methods, in any context, is a perfect indicator of a bad programmer who has no idea what OOP is.
Why? How so? I am not sure that this is explained in the book, or I somehow missed it.. The points below are either "disadvantages" or "reasons" why static methods should not be used..

Object vs. Computer Thinking
According to the book,
int max(int a, int b) {
    if (a > b) {
        return a;
    }
    return b;
}
should be written as..
public class Max implements Number {
 
    private final Number a;
    private final Number b;
 
    public Max(Number a, Number b) {
        this.a = a;
        this.b = b;
    }
}


  1. Where is the static method?
  2. How does class Max return the maximum of a and b?
This chapter is just confusing..

Declarative vs Imperative Style
This is the example given in the book..
public void doItDeclarative() {
    Integer x = new Between(5,9);
    if (/* Do we need it?*/) {
        System.out.println("x=" + x);
    }
}
This does not tell the CPU to calculate everything. Instead, it lets the CPU decide when and where the result is actually needed, the calculation happens on demand.
And this is the counter example, given in the book:
public void doItImperative() {
    int x = Math.between(5, 9);
    if (/* Do we need it?*/) {
        System.out.println("x=" + x);
    }
}
Well yes, but what is keeping you from..
public void doItImperative() {
    if (/* Do we need it?*/) {
        int x = Math.between(5, 9);
        System.out.println("x=" + x);
    }
}
This example does not show anything about why we should not use static methods, or does it?

Utility Classes
A so-called "utility" class is not really a class but a collection of static methods used by other methods for convenience. Utility classes are a terrible anti-pattern in OOP. Stay away from them.
This is all in this chapter.. Really. Why? I do not know.. Just stay away from them.. OK!

Singleton Pattern
Singleton is famous for being a "design pattern", while in reality it is a terrible anti-pattern. What is the difference between a Utility Class and a Singleton Class? A Singleton Class is a dependency that is possible to break, while a Utility Class is hard-coded tight coupling that is impossible to break. If a Singleton is big, I may need to "mock" it or just replace it with something more suitable for my testing purposes. 
We can still mock a Utility class..
package biz.tugay.canimock;
 
class MyUtilClass {
    static int myUtilMethod() {
        return 5;
    }
}
 
package biz.tugay.canimock;
 
class MyTestClass {
    int foo() {
        return MyUtilClass.myUtilMethod() * 2;
    }
}
And this is how I will simply break the dependency..
package biz.tugay.canimock;
 
import org.junit.Assert;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.BDDMockito;
import org.powermock.api.mockito.PowerMockito;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;
 
@RunWith(PowerMockRunner.class)
@PrepareForTest(MyUtilClass.class)
public class MyTestClassTest {
    @Test
    public void foo() throws Exception {
        PowerMockito.mockStatic(MyUtilClass.class);
        BDDMockito.given(MyUtilClass.myUtilMethod()).willReturn(10);
        final MyTestClass myTestClass = new MyTestClass();
        final int foo = myTestClass.foo();
        Assert.assertTrue(foo == 20);
    }
}
Don 't use Singletons, ever. Say, we really need most of our classes to know who the user that is currently logged in is. We don 't have utility classes and we don 't have Singletons. What do we have? Encapsulation! Just encapsulate that User in all objects that may need it.
Is not that a bad idea? How is this useful? I guess Singleton is fine, only for very specific things, such as Database Connection Factories, or "the logged in User".

The remaining 2 sub-chapters are just non - sense.. Seriously.. They are "utopias", exactly as stated in the book itself. I agree, they are utopias.. No need to go through them.

So final verdict: Do not use Static Methods! But why? Because I say so..