Author: Dan Iftodi
Martin Fowler @ OOP2014 “Workflows of Refactoring”
Over the last decade or so, Refactoring has become a widely used technique to keep a high internal quality for a codebase. However most teams don’t make enough use of refactoring because they aren’t aware of the various workflows in which you can use it. In this keynote talk from OOP 2014 in Munich, Martin […]
Favor composition over inheritance
Inheritance is a powerful way to achieve code reuse, but it is not always the best tool for the job. Used inappropriately, it leads to fragile software. Unlike method invocation, inheritance violates encapsulation. In other words, a subclass depends on the implementation details of its superclass for its proper function. A class B should extend […]
Minimize mutability
An immutable class is a simply class whose instances cannot be modified. All of the information contained in each instance is provided when it is created and is fixed for the lifetime of the object. Don’t provide any methods that modify the object’s state (known as mutators) Ensure that the class can’t be extended. This […]
In public classes, use accessor methods, not public-fields
Occasionally, you may be tempted to write degenerate classes that server no purpose other than to group instance fields:
|
1 2 3 4 5 |
//Degenerate classes like this should not be public! class Point { public long x; public long y; } |
Because the data fields of such classes are accessed directly, these classes do not offer the benefits of encapsulation. You can’t change the representation without change the API. If a class is accessible outside its […]
Minimize the accessibility of classes and members
The single most important factor that distinguishes a well-designed module a poorly designed one is the degree to which the modules hides its internal dara and implementation details. A well-designed module hides all of its implementation details, cleanly separating its API from its implementation. Information hiding doesn’t cause on itself good performance, it enables effective […]
Consider implementing Comparable
Comparable interface provides compareTo method which is similar with Object’s equals method, except that it permits order comparisons in addition to simple equality comparisons, and it is generic. By implementing Comparable, a class indicates that its instances have a natural ordering. Sorting an array of objects that implement Comparable is as simple as this:
|
1 |
Arrays.sort(a); |
[…]
Override clone judiciously
The Cloneable interface was intended as a mixin interface for objects to advertise that they permit cloning. Unfortunately, it fails to service this purpose. Its primary flaw is that it lacks a clone method, and Object’s clone method is protected. You cannot, without resorting to reflection, invoke the clone method on a object merely because […]
Always override toString
While java.lang.Object provides an implementation of the toString method, the string that it returns i generally not what user of your class wants to see. It consists of the class name followed by an “at” sign (@) and the unsigned hexadecimal representation of the hash code, for example “PhoneNumber@163b91”. While it could be argued that […]
Always override hashCode when you override equals
A common source of bugs is the failure to override the hashCode method. You must override hashCode in every class that overrides equals. Failure to do so will result in a violating of the general contract for Object.hashCode, which will prevent your class from functioning properly in conjunction with all hash-based collections, including HashMap, HashSet […]