Java Object-Orientation
This Object-Oriented programming page includes the
following
This web page does not dive deep into OO concepts
(there are numerous books on the subject that are far better explaining the OO
concepts than me) but outlines the basic OO concepts and any rules that you
need to know, again this is intended to be a quick guide.
OOP encapsulates data (attributes) and methods
(behaviors) into objects, the data and methods are intimately tied together,
implementation details are hidden within the objects themselves. In Java the
unit of programming is the class from which objects are eventually
instantiated. Methods and data are encapsulated within the walls of the class.
A class contains the data and the methods that access the data contained within
the class. The data contained in a class is called the instance variables.
Encapsulation
The ability to make changes in your implementation
code without breaking the code of others who use your code is a key benefit of
encapsulation. You want to hide (mask) implementation details behind a public
programming interface. By interface we mean the set of accessible methods your
code makes available for other code to call, in other words, your codes API's.
You can change the code without forcing a change in the code that calls your
changed methods.
To provide maintainability, flexibility and
extensibility you must encapsulate the code and to do this you
Keep your instance variables protected (using the
private access modifier)
Make public accessor methods and force coding to use
those methods
For the methods use the JavaBeans naming convention
(set (mutator) and get (accessor) methods)
Set and Get methods
public class Football {
private
String team; // this is
hidden to the outside world
private
int groundCapacity; // this is
hidden to the outside world
public void
setTeam(String t) { ... }
public
String getTeam() { ... }
public void
setGroundCapacity(int c) { ... }
public int
getGroundCapacity { ... }
}
Note: the only way to get to the instance variables
is via the set and get methods
When you create a new class that does something you
will document only what access methods (get and set) are available to the
public and this will not change, whoever implements your class can get updates
and improved versions knowing that implementing this newer version will not
break his/her program as the return types and passing variables to methods will
be the same.
State
the benefits of encapsulation in object oriented design and write code that
implements tightly encapsulated classes .
Encapsulation
The principle of encapsulation is that all of an
object’s data is contained and hidden in the object and access to it restricted
to methods of that class.
Code outside of the object cannot (or at least
should not) directly access object fields.
All access to an object’s fields takes place through
its methods.
Change the way in which the data is actually stored
without affecting the code that interacts with the object
Validate requested changes to data
Ensure the consistency of data — for example
preventing related fields from being changed independently, which could leave
the object in an inconsistent or invalid state
Protect the data from unauthorized access
Perform actions such as notifications in response to
data access and modification
Encapsulation is the principal of keeping the
internal details of a classes state and behaviours hidden from the other
classes that use it. This allows you to change those details where necessary,
without breaking compatibility. The interconnectness between pieces of code is
called 'coupling', and minimising it makes for more reusable and maintainable
classes. The expectated behaviour of a class or method is referred to as its
'contract'. You do not want to expose any more than the minimum required to
support the contract, or you can end up with tangled interdependent code with
poor maintainabilty, and in all likelyhood, poor quality.
Encapsulation also aids polymorphism and inheritance
- if the internal details of a class are exposed and used, it is very hard to
substitute a different implementation of the same contract.
To achieve good encapsulation, make everything have
the tightest possible access control so if something should not be used in a
given context, limit the access to prohibit it. In particular, class instance
variables should be private, and accessed only through 'get'/'set' methods
(a.k.a accessors and mutators). This would allow you to do some work or
checking before reading/writing a value to the variable. You could remove the
variable entirely and derive it or obtain it from another source. If the variable
was public, and was accessed directly, should changes would break client code.
