Rails Summit finished a few days ago and I have only one word to describe it: Awesome!
I met some really cool people, discussed a whole bunch of technical subjects and managed not to get so nervous in my first presentation ever - I’m not counting internal presentations I’ve done for my team…
My slides and source files can be found here. Feel free to contact me with questions if you got any.
Once more my life is taking a huge turn.
I’ve been pretty quiet for the past month and honestly don’t know how I managed to hold in my excitement. I’ve just accepted an offer from ThoughtWorks to be based at their australian offices, either in Sydney or Melbourne, depending on where my 1st project will be.
For those of you who don’t know, ThoughtWorks is a global IT consultancy that is really well known in the software development community. It’s been advocating agile methodologies and test-driven development for several years now and seems to work really hard to attract and keep many bright people working there.
As a result, ThoughtWorks inspires companies and professionals around the world by delivering high quality projects and massively supporting/contributing to open source projects.
Needless to say, I am really excited to be joining a company with such an amazing culture and so many smart people.
The hiring process was long, tough and tiring - but yet enjoyable. It took 5 interviews, 1 code review and 1 pairing session, a process through which I talked to 8 thoughtworkers. They take pride on their hiring process and now I understand why.
Now I’m just going through the bureaucratic side of things: gathering documents, certificates, translations - all in order to apply for my VISA, which can take up to 3 months to get ready. In the meantime, you can still find me here in Madrid, where I’ll be celebrating with a few ‘cañas’. Feel free to join me! 
I said final classes are evil and that post got some attention with interesting comments. Maybe because of the title and the tone I wrote it, a few comments didn’t get my real intention and perhaps I should have been more explicit about it. Go ahead and read it. I’ll wait. 
Anyway, I thought I’d expand a little more on that subject, explaining my motivation to write that post and going through the topics I think were raised by my dear readers.
First off, final classes are evil for testing. And that’s what it was all about in my previous post.
If you depend on a final class, your code will be harder to test. Unless the final class provides an interface that captures its intent - or you wrap that dependency.
But this affirmation has some implications that were pointed out by a few comments, some of which I agree with - others, not so much. So let’s start!
- Immutability
Someone said “Why make a class final ? To make it immutable”. This is not entirely true. Only by marking it final you do not ensure immutability. There is no point in doing that if you provide mutators - e.g. setters. - and don’t declare your members private and final.
I think it’s important to make this clear and understand that the immutability part you achieve by marking a class final is the one of preventing inheritance. Subclasses could possibly contain malicious/careless code and change the internal state of the class.
But there is another way of preventing subclassing without marking the parent final: declare its constructor private and provide a static factory.
- Designing for extensibility
This is hard. It basically means that if you don’t mark a class final, you should document it for inheritance.
And this is why inheritance is, in general, a bad OO practice. By documenting the class you basically break encapsulation since you tell the world about your internals.
Therefore, the recommendation is to mark a class final if you’re not sure if it’s safe to subclass it - or if you just don’t wanna bother writing documentation and thinking too much about your “client” subclasses.
- Coding against interfaces
This one is simple but yet often forgotten. Do not code to concrete classes. Always choose interfaces where possible.
It roughly means to do this:
List args = new ArrayList();
instead of this:
ArrayList args = new ArrayList();
By doing so you have the flexibility to not care about the implementation you’re working with, as long as it obeys the interface. That way, the implementations can be swapped at any time without breaking any client’s code.
- The problem with testing
All items listed here so far are widely regarded as best practices and the bullet I raised about hard testing usually happens when you “violate” some of them.
Specifically, if you decide not to design a class for inheritance and mark it as final, it’s wise - in my opinion - to try and capture the class’s intent through an interface.
That way you can safely mark your class final and users of your class can easily use the interface to extend it - by favoring composition over inheritance - or by providing it to mocking frameworks for easy testing.
- Conclusion
I don’t really think there is a rule of thumb here. Java’s standard library shows many examples of both approaches and some of them are now considered bad practices but yet are there for backward compatibility. Nevertheless, these are points to consider when designing your classes.
As pointed out by Josua Bloch in his awesome book Effective Java, “If a concrete class does not implement a standard interface, then you may inconvenience some programmers by prohibiting inheritance”.
As usual, comments are more than welcome
