You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

(warning) Under construction

API design guidelines

The following guidelines are meant to make the user experience more pleasant. They are aimed to help the user make use of existing tools and increase productivity. As a first guideline, keep in mind that somebody other than you will use your code.

Object orientation

Object orientation is a design approach that attempts to model real world objects in the code.
Try to think in objects.
Make use of the visibility of objects.
Hide your implementation from the user.
On the other hand, not every class needs to have a set of private data members with a full-blown set of Setters and Getters. It is ok to have a class with only public data members.
Rule: What belongs together logically should be handled together
Example:

(thumbs up)

(thumbs down)

Optimization

Optimization obfuscates code. It also forces you to change your intuitive approach.
Rule: First, write your code. Then profile it. Then, if necessary, optimize it.

Status codes

In the good old Fortran and C days, obscure statuscodes and bitfields were common sight. While it is true that your code should be optimized at the persistence level, make sure you include definitions of your statuscodes in the API. The use of Enum, EnumSet and EnumMapis encouraged.

(thumbs up)

(thumbs down)

enum MyClassFlags {doThingX, doThingY, doThingZ};
    class MyClass {
    MyClassFlags flags;
    void setFlags(EnumSet f) {flags = f;}
}
...
EnumSet<MyClassFlags> myFlags = new EnumSet<MyClassFlags>();
myFlags.add(MyClassFlags.doThingX); // yes, it is more verbose. That is a good thing !
MyClass c;
c.setFlags(myFlags);
class Obscure {
    int obscureFlag;
    void setObscureFlag(int o) {obscureFlag = o;}
}
...
Obscure o
o.setObscureFlag(3);

Never hardcode numbers

"Overloaded Operators"

It is very confusing to have members like add(Object o1, Object o2) as members of the classes. This is counter-intuitive. Either there ought to be a supporter class with static members only, or the member of the type class expects only one argument.
So, design it to look like this:

(thumbs up)

(thumbs down)

vec1.add(vec2);

or

import static x.y.add; add(vec1, vec2);
vec1.add(vec1, vec2);

Using strings to access parameters

Strings should be used for input/output operations. They are slow to parse and cannot be checked for typos at compile time.
Using them to set flags and parameters is not recommended.

  • No labels