Working with classes and objects is a very sophisticated approach to programming. You can't expect to absorb all of its implications in one go. We have already looked at the basics of class and objects. Now we need to look at encapsulation, constructors, overloading and inheritance.

Working with classes and objects is a very sophisticated approach to programming. You can't expect to absorb all of its implications in one go. In the previous chapter we looked at the basics of class and objects - now we need to look at some of the slightly more advanced ideas.

In this chapter we will learn about encapsulation, constructors, overloading and inheritance.

One of the problems in convincing any beginner that class and object are worth the effort, is that they lack the experience of programming without such ideas.

In the early days of programs were written as large blocks of code with little or no structure. They were essentially long outpourings of logic and to understand what is going on you had to understand it all. later we learned that it was better to divide a program up into small units called functions or procedures. This worked reasonably well but it didn't treat the data that the program worked on in the same way and there was the problem that functions tended to work in groups to get tasks done with the same sort of data.

The solution to the problem was to invent a second level of grouping. A class and the object it creates is a grouping of functions and data as methods and properties and this idea brings us to our first topic - encapsulation.

Encapsulation

Encapsulation is the jargon word for keeping the inner workings of a class hidden from the outside world.

Why would you want to do this?

A class does a particular job and it is used by other parts of the program and perhaps other programmers to get that job done. If the internal workings of the class are accessible perhaps you or some other programmer will make use of them in ways not originally planned. If you then change the way the class works then things fail.

As a general principle it is much better to keep the interactions between different parts of a program to well defined areas. In this way you can make changes to the internals without having to worry about other parts of the program.

You get some aspects of encapsulation more or less automatically when you use classes.

For example, any variable you declare within a method isn't accessible from out side of the class.

However, when it comes to member variables and member functions, i.e. properties and methods, you actually have to make some decisions.

So far we have used the keyword public in front of member declarations but there is also the choice of declaring them private.

A public member is accessible from other classes but a private member can only be used by other members of the class.

Get/Put Properties

Clearly all of the internal workings of a class should be declared as private but there is a lot of argument over what constitutes the internal workings of a class.

In the strictly orthodox approach you should declare all data variables as private. In other words, our approach to properties, outlined in the previous chapter, is not good enough.

Why?

Simply because allowing another class direct access to a variable or any data gives it the right to do anything at all to it. If you make all variables private then you have to provide access member functions which allow other classes to set and get the values.

The advantage of get and set functions is that they can include code to check that the value is legal and perform whatever data conversion is necessary to change from an external to an internal representation. You can also arrange for things to be updated if a property changes its value.

Set and Get are usually referred to as "mutators and accessors" because the modify and retrieve the property values.

So using this approach for example, the point class used in the last chapter would be written

This may seem a time wasting idea but now imagine that you need to change how a point is represented within the class, perhaps as an angle and a distance. You could leave the outside world working with x and y and use the set and get routines to do the conversion.

Not convinced?

Well a lot of object oriented programmers drop the set and get idea mostly out of laziness rather than by way of an informed decision but you should recognize the set/get idea as how Swing implements its properties. All properties of Swing objects such as buttons work with set/get methods. If it is good enough for Swing it should be a recommendation you take notice of.

Some programmers take this idea one step further. They hold to the view that an object should never give up any data. If something needs to be done to a property then the object should do it not pass the data out to another object to process. This stronger position is a little more controversial and most programmers strive for an ideal but are happy to compromise is there is a pay off.