Many times after a Java Interview I have asked myself if my answers were correct, if the person interviewing me realized that I understand a certain concept and if I was able to express my knowledge in order to achieve that. So I will start writing on my blog how I would answer some common Java Interview questions.

So, in Java what are the differences between an abstract class and an interface?
This is a question with one big answer, not only because there are that many differences between abstract classes and interfaces, but because there are so many ways to say it. So, here is what I would say about interfaces:

Interfaces are equivalent to protocols. They basically represent an agreed-upon behavior (a contract) to facilitate interaction between unrelated objects.

Interfaces are a capsule for a group of methods with empty bodies or prototypes (abstract methods ) and implicitly final static members (constants).

Interfaces have all members public impilicitly.

Interfaces are declared like this:

public interface TestIntf {}

Interfaces can only extend other interfaces and keyword implements does not apply to them.

Interfaces are considered to be slower because they require extra indirection to find the corresponding method in the class implementing them.

Interfaces support only public and default access modifiers.

Interfaces can be declared abstract, so the Java compiler would not complain if your declaration would look like below, but the abstract modifier is redundant as interfaces are implicitly abstract.

public abstract interface TestIntf {}

Here is what I would say about abstract classes:

Abstract Classes are the middle ground between interfaces and classes. They can have both abstract and non-abstract methods and constant and non-constant fields.

Abstract Classes can have constructor, but it can never be called directly. It can only be called using super in the extending class or is automatically called by the jvm.

Abstract Classes support all access modifiers.

Abstract classes can be declared like this:

[access_modifier] abstract class TestAC { [ implementation] }

Abstract Classes can implement any number of interfaces, can extend only one class (which can be abstract or not – the condition is not to be final) and implicitly extend class Object.

Abstract Classes can have only non-abstract methods (but what would be the point?). Abstract Classes which have only abstract methods and constant fields are called fully abstract.

And what would I say about both of them:

Java supports multiple inheritance only through interfaces.(Some say it is limited. I say it is practical.) Why? Because extending multiple classes may lead to problems when they have methods with identical signatures. (Remember C?)

The use of interfaces or abstract classes is determined by the project requirements and design.

Well, we have a VM with Gentoo and an interface. Let’s make the virtual machine more flexible and more cooperative with the operating system on your computer. For this we have to install VirtualBox drivers on your Gentoo. After restarting your system upon setting up the interface you can log on to your desktop interface. But for installing other tools you will still need the console. For the purpose of this tutorial we will use the Kde terminal named konsole.

To open a terminal: click the button on the left corner of the screen (the “K” button) and in the menu that is displayed at the top there is a text field. Type konsole and click on one of the results returned. (print-screen) Or press Alt +F2 and the same text field will appear at the top of your desktop. You can use it to start any application you want. You will be logged in with the normal user so in order to install things you need root access. So, in the terminal you need to use the su command:

# su -

You will be asked for the root password which you will type and then you can start installing. (By the way if any emerge process happens to fail, you can force to continue by using: # emerge –resume)Continue reading “VirtualBox with Gentoo(3)”

You’ll find the internet a lot of opinions regarding this matter, but I really want to post here the way I do it, because it might be useful to someone. Being a Java developer, of course I’ll be referring to Java projects, but the steps are common to all projects, regardless of the technology used to develop them.

This is how I do it:

I decide de name of the project. Any project has to have a name that tells a first time user what it does. The name mustn’t be too long or too complicated. The last project I worked on was called Expenses Manager. Well, what do you think? Can you easily infer what it does?

Based on the name of the project I name my packages. Any JBoss package name has jboss in them, any Hibernate package name has hibernate in it and so on. But when the project name is long, like mine was, it is recommended to create a short name composed of the starting letter of the words which compose the project name – in my case em. For example one package of my application was called jj.em.test, jj is my nickname and test is the scope of the classes inside this package, in this case, classes used for testing. Some developers precede package names with com or org. Anyway you decide to name your packages the main purpose is to help a first time developer looking at your code understand the way the project was organized and why.

I Define a logger for my project. Although there are a few logging libraries on the web, my recommendation is to keep things simple and not make your jar bigger than it needs to be or to complicate yourself with classpath stuff. How do you keep things simple? By using java.util.logging.Logger the logger class provided by the jdk. If you want an example here is a console simple logger implementation and here is a simple file logger implementation. (I dare you to do better!) Why would you need a logger? Because you might need to see outputs, values of your variables at a specific step in development without switching to debug and using breakpoints and stuff, because this might slow you down. When you no longer need the logger, you can just turn it off and all the gibberish disappears.

I set up a testing environment or module. Your application will need testing, no matter how small you might consider it to be. It is better to start with a few test classes which you will grow in parallel with your application by adding new test methods. Same as internationalization (point 5), starting to develop the test module when your application is already done might be a pain in the ass.

I Internationalize! You might ask, why is this a key step and why is it really needed? Well, my dear readers, any time you start a project you must think that might be useful not only to you but to people that one day might actually pay for it. Look at the big picture, and internationalize at the beginning, because if you need to do this later, it will be a big pain in your smart ass!

I Use a building tools like Ant or Maven. Ant for small projects, Maven for big ones which have a lot of dependencies. Also, you might want to check out JRebel.

This week I went to another java interview. Yes, another one, because I still have no job. Don’t ask me how that happened because I don’t know. Maybe I just did not find a company that I would love to work at, enough to keep my mouth shut and not piss off the guys at HR. Besides all the simple questions, that I usually fuck up because I do not pay enough attention, at this interview, I was asked to describe “The Decorator Design Pattern”(which is actually a structural pattern by some authors). And of course I did not write one word, because even if lately I read a book about design patterns I did not remember which one was “The Decorator Pattern” and what was it about. Usually when I program I design my own classes, interfaces hierarchy and database, because except the two titan projects I worked at while being part of a medium team, my applications are small, simple and useful only to me and a few of my friends. So like I said, I design and implement everything and I don’t care that some big hot-shot developers have bagged and tagged some programming techniques and wrote books about it.

But sometimes when you are asked about these programming techniques at interviews you feel frustrated that you did not learn your programming theory part.This is how I felt Monday morning. So on my way home I decided to start a series of posts on this blog about all “bagged and tagged” programming techniques also called “Design Patterns”. Maybe writing about them will make me remember them and not feel frustrated at an interview ever again.