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

Notes from first half of Chapter 2.

Encapsulate as little as possible

I recommend you encapsulate four objects or less. Four or fewer. Encapsulated objects, all together, are also known as the "state" or the "identity" of the object. 
My Notes
I guess the suggestion is reasonable, except the "maximum four" part.. Just try to keep it small.

Encapsulate something at the very least

So, you should not have code like this:
public class Year {
    void read() {
        final long currentTime = System.currentTimeMillis();
        final long currentYear = currentTime / 31104000000L + 1970L - 1L;
        System.out.println(currentYear);
    }
}
..but rather..
public class Year {
 
    private long currentTime;
 
    public Year(long currentTime) {
        this.currentTime = currentTime;
    }
 
    void read() {
        final long currentYear = currentTime / 31104000000L + 1970L - 1L;
        System.out.println(currentYear);
    }
}
My Notes
This is dependency injection, isn 't it? And yes, I think the second design is better. You can test it easier as well.

Always use Interfaces

Skip this one, totally agree.

Method Names

According to the book..
  • builder methods should be nouns.
  • manipulator methods should be verbs and return void.
  • boolean methods should be adjectives.
Here are some examples..
public interface MethodNameExamples {
    // Wrong method naming
    InputStream load(URL url);
    String read(File file);
    int add(int x, int y);
 
    // Correct method naming
    InputStream stream(URL url);
    String content(File file);
    int sum(int x, int y);
}
And another example, again from the book..
public interface Document {
    int write(InputStream content);
}
So the principle is violated here. The method is a manipulator, not a builder.. It should return void. But how do we know how many bytes have been saved? The author suggests the following refactoring..
public interface Document {
    OutputPipe outputPipe();
}
public interface OutputPipe {
    void write(InputStream is);
    int bytes();
    long time();
}
My Notes
I will start with the latter example above, the one with the OutputPipe. Why are the new methods not simply in the Document interface, but rather in a new Interface? Also the reasoning behind this is, author says that write method should be responsible only for writing and not returning the bytes written so the method is unfocused.. Well now it is responsible for writing and storing? I really do not see what the harm is with returning the bytes written.

And regarding the boolean methods should be adjectives the suggested method names in the book are as follows..
public interface BooleanMethodNames {
    boolean empty();
    boolean readable();
    boolean negative();
}
I honestly have no idea how empty() is more readable or cleaner compared to isEmpty().. I even think it is worse!

Don 't use public constants

I am currently lazy to add examples here but I guess we can keep using public constants.. The example given in the book is just way too specific and obviously picked for reasoning this suggestion.