Skip to content

Buy a good Java book

November 7, 2011

If you want to learn Java, then write Java.

If you want to write Java, get a book that presents topics the way your brain prefers.  I got a book called Head First Java and have been working with it couple weeks.  I like the way it  presents content and emphasizes that you MUST do something with its content to retain it.   Information is abstract by nature, it MUST become concrete to stay in your brain.  You must grok the concept for it to stay in your pocket, avail. for future reference.

If you want to learn something, not memorize, but learn it, you must roll around in it, bath in it, take it to the movies and to lunch.  Take it to play and even to bed.  In other words, it takes time and many visits before you really know someone, I mean something.

I take Java out to lunch most weekdays.  I took it home this weekend, we had quality time together. I shared my pancakes before church.

Spending time is the half of getting to know Java, the other half is spending the time in a way that is memorable.  Its not enough just to make time, I have to make good use of the time.  I have to listen to Java, hear what it has to say.  I have to listen to the many different ways that Java wants to speak to me.  A very important step is to allow my brain time to really think about and apply what Java is saying to me.

This is why I like Head First Java so much.  She can speak to me for long periods of time in many different ways.  Java uses plain ole English, but supplements with examples, puzzles, bullet points, problems, humor,  illustrations and more.

These are the very specific things that Java has been helping me to understand at a deeper level.

You can stop reading now if you are not interested in some of the gory details.

  • I will no longer allow my law of implementation knowledge effect how I design classes.  In other words, i have know for a long time certain software design concepts that are well established but sometimes would work away from them because i could not get them to implement properly.
  • I will keep data, instance variables in my classes private.  Declare them outside of any method, and then initialize them in the constructor.  Then I can reference them from any other method avail. to the class.  This scenario is good for most of the software that you design.
  • Objects are implementations of your classes.  Objects have their own state.  The state is represented by the instance variables in the object.  The state can and likely will change during the life of the object.
  • Let your application consist of lots of *smaller objects – which means smaller classes.  If you design you software with smaller classes, it really is easier to test, debug and update. This is a little abstract until you start to do it.
  • Think of your application as a collection of objects, objects that speak to each other during their existence.  Object message each other via the object methods.
  • If you are building classes that could be used outside of your application, like most of the public classes in the Java API, then use a interface to explain what the methods are that exist in the class.
  • When in doubt, use a private scope on your instance variables.  If you have instance variables that need to be shared by other classes, use a protected scope.  Avoid the use of public ally scoped variables.
  • Use constructors in your classes to initialize instance variables.
  • Most of your classes will not have a static main method.  A static main method is used to launch the application.  It does not contain state, is only ever called once, and is not an object.  You will see the main method in many examples, since they are well, examples.  Notice that most classes are not launched, but are instantiated.
  • Use a test class to test the class you are creating.  Don’t add a main method to your class just to test it.  Create a test class for this purpose that will not be part of the final deployment.
  • In your application, there should be only a single entry point.
  • Keep your methods simple.  If your method is doing too much, refactor it and break it into multiple methods.  It may be more work to design this way, but is worth the time saved in debugging and maintaining.
  • Think of the person who will come along after you and will maintain your classes.  Document them and keep them as *simple as possible.  Simple meaning well organized, documented and designed.

From → Java

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: