Coding guidelines

Here is the FastODS interpretation of some classic coding guidelines. FastODS code is written in accordance with this interpretation.

Understanding these guidelines may:

• help users to understand the codebase
• help contributors

General guidelines

Principle	FastODS interpretation
Single responsibility principle	As few private methods as possible: a private method is either useless or should be attached to a specific class. This class is package private, and the method become public and testable. Classes are short, excepted the facade classes.
Open closed principle	Wait for 1.0.0 release .
Liskov substitution principle	Do not hesitate to create interfaces.
Interface segregation principle	Do not hesitate to create interface hierarchies.
Composition over inheritance	No inheritance, no magic! Every method is explicitely delegated to the class that will handle it.
Use overloading judiciously	Each class has only one constructor. This make the class more testable. There may be static methods to create an object with default parameters.
Minimize mutability	Use the builder pattern and avoid setters. A class that is not initialized by the constructor will be responsible for reaching a correct state with setters, and thus has at least two reponsibilities.

Note The dependency inversion principle is less useful in a specialized library like FastODS.

Tests

FastODS tests follow the record/replay/verify principle.

The canonical form of a FastODS test with mocks is:

public void test() {
    // create objects

    PowerMock.resetAll(); // this is the signal for record
    // record

    PowerMock.replayAll(); // this is the signal for replay
    // replay WITHOUT assertions

    PowerMock.verifyAll(); // this is the signal for verify
    // assertions go here
}

If there is no assertion in the whole test class, PowerMock.verifyAll() is in a tearDown method.