Final should be Default for Classes in Java
David J. Pearce wrote an interesting post on why classes should always be final by default, unless otherwise defined. The argument goes like this: non final classes can be extended, and thus rely on their parent class. You can also override methods in the parent class and change their behavior, something that may come back to bite you later (when the parent class change. You risk introducing complexity and dependencies in your application.
Since what you want is to keep the code as clean and simple as possible you want to favor composition over inheritance. Having all classes final by default forces development in that direction, and introduces an obstacle in taking the easy road (that is, use inheritance way to much).
An anecdote in regards to version control
A younger programmer asked an elder about his code and his coding style, and how the older programmer would do certain things. The older programmer said ‘Let’s take a look at your code’, so the younger took out his laptop, opened his editor, and showed him.
The older programmer looked at the code, thought about it for a bit, and then started editing it. He deleted the class internals, leaving only the structure, and then rearranged the structure, saying ‘Here’s how I would do it to make it more efficient and readable’. After he was done, he saved the file and gave it back to the younger programmer, who was ashen-faced.
‘That… My code is gone!’ said the younger programmer. ‘But you have it in version control somewhere, right?’ asked the elder. ‘N…. no.’ was the reply. ‘Well then,’ said the older, ‘now you’ve learned two lessons.’
(source: Stack overflow, via Glenn Stovall)
Great site for showing little UI tricks that can make a big difference.
Excellent breakdown of how we select passwords.
Write simple parts connected by clean interfaces
There is a company that used to be a shining example of this rule, but they have lost their way. That company is Lego. take a look at a recent star wars set they have released:
[…]
You can see there are many parts that are specific that would only work in this set (particularly on the top of the ship).
[…]
For multiple Lego bricks to interact they just need to do 1 of 2 things: have other Lego brick snapped to the top of them, or be able to be snapped to the bottom of another Lego brick. In a stroke of genius, Lego actually made it so that their standard Lego bricks can connect with their larger duplo blocks. These two systems designed to work separately can also be connected together.
Coding is the same way, you parts must have simple interfaces so that other code can know what it does, and it can know what to expect from other code.
Because random Strings that start with 4, 8, 15 might not be so random after all.
