This post originated from an RSS feed registered with Java Buzz
by Ben Hosking.
Original Post: Hiding the Implementation and separating the things that change from the things that stay the same
Feed Title: A Funny Java Flavoured Look at the World
Feed URL: http://businesslogs.com/WebLog/RSS.xml
Feed Description: The blog looks at using Java and programming in general as it pops up in life as a Java programmer. It will have links to interesting Java articles and resources. It will also have a lot of SCJP Java 1.5 information and links as I am currently studying
I have recently been thinking of my code as a public API and being careful what I show to other classes using my classes. Viewing classes in this light also help to reduce coupling with other classes. The big benefit this has also is it hides the implementation of a classes methods from the users of the class.
The real benefit of this is that you can then change how the methods do what ever they are doing with the user worrying or knowing (assuming it still works the same way)
This is where Interfaces come into play, where methods hide the implementation of one method, an interface can be used to hide numerous classes implementing that method.
The reason why I am talking about this is because I saw this quote today about one of the goals of Object-Orientated design is
"separating the things that change from the things that stay the same."
someone was looking at my code yesterday and laughed because I had a class called
"HardCodedClientValues"
The deadline for a customer project was brought forward by about a week and I had to write an initial version of the code in 2/3 days. They said hard code everything and just get it done. Knowing that I would have to write it properly a few days after I decided to hide the implementation of the hard coded values behind an interface. Basically there are a number of values that I have hard coded but I think the user would like to have the ability to change them in the next release.
So I created an interface called LLPGSearch and have initially then created a new version of the HardCodedClientValues class and then the rest of the code works using the values it gets from the interface. So now when I have some more time and improve the code, instead of using the HardCodedValues class I will collect the values from some property or xml files but fit them into a class which implements the LLPGSearch Interface which should hopefully mean the rest of the code will work not knowing that I have changed what's behind the interface. Basically showing that by hiding the implementation using an interface I have separated the things that change from the things that stay the same.
I liked this code because firstly it seemed funny to me and other developers to see someone write a class called "HardCodedClientValues" and I don't think they understood what I was doing. It was also interesting for me because it was hiding the implementation but I wasn't thinking about that by name but realised that I had done that when I read this good explanation of Hiding the implementation from Thinking in Java 3rd
Previous Topic
