Access Modifiers | Private, Public & Protected

An access modifier determines the visibility of a class member (states & behaviours).

An access modifier of Public allows a class member to be accessed from external objects & is denoted on a class diagram with a + (addition) symbol.

A Private access modifier allows only internal access and prevents access by external objects. Private access is denoted on a class diagram with the - (minus) symbol.

The Protected access modifier allows internal access and access by child classes. Protected access is denoted on a class diagram with the # (hash) symbol.

Why hide object state?

By restricting access to an objects internal state via getter behaviors, we can ensure that all values are valid before assigning them to internal state.

For instance, the Player class has a state called Name. If an external object has direct access to this state, there is the possibility that an incorrect or invalid value may be assigned to it, however, if that state can only be modified via a setter behavior, the behavior implementation (code) can check the value for its validity before assigning the value to the Name state. Eg. Is the name the correct length, type, etc.

Mutators: Set

Classes may contain mutator behaviors for some or all of their states. This enables other objects to change the value of a state. A mutator behavior is usually implemented as a subroutine, unless there is a requirement for a return message - such as a confirmation that the change took place, in which case you would use a function (which could return a value, such as True or False).

A setter subroutine requires a parameter which represents the new value of the state.

For example, the Player class now contains a number of mutator behaviors. Following convention, the names of these behaviors begin with the word Set.

In a class diagram, the format for a setter behavior(subroutine) looks like this:

Visibility SubroutineName(Parameters: DataType)

...as can be seen in the Player class example:

+SetName(NewName: String)

The implementation (code) for a mutator, reads the parameter that is passed to it and updates the value of the state with the value of the parameter. In other words, the SetName() function will read the String parameter passed to it and then change the value of the Name state.

An mutator behavior has visibility of Public.

Accessors: Get

Classes may contain accessor behaviors for some or all of their states. This enables other objects to read the value of a state. An accessor behavior is nearly always implemented as a function, as a function returns a value to the calling procedure.

For example, the Player class now contains a number of accessor behaviors. Following convention, the names of these behaviors begin with the word Get.

In a class diagram, the format for a behavior that returns a value(function) looks like this:

Visibility FunctionName(ParametersIfAny):ReturnDataType

...as can be seen in the Player class example:

+GetName():String

The implementation (code) for an accessor, reads and returns the value of the state being accessed. In other words, the GetName() function will return a String (containing the value of the Name state) to the calling procedure.

An accessor behavior has visibility of Public.

Visibility: Private & Public

Following the laws of encapsulation, when designing a class, it is important to define the visibility of the states and behaviors contained within the class. This is known as visibility.

Notice in the class diagram below, each state has a minus preceding its name and each behavior has a plus preceding its name. A minus denotes that a state or behavior is private and cannot be directly accessed from external objects. A plus denotes that a state or behavior is public and may be accessed externally by other objects.

When an object state is private, no other object can read or change the value.

 

What is Encapsulation?

Encapsulation is the process of packaging the base functionality of a class and providing access to the features of the class through a collection of behaviors. This means that the inner workings of the class are hidden from other classes and cannot be directly accessed.

Objects are responsible for maintaining their own state & behavior.

This means that a Sword object should not be able to directly manipulate a Player state and vice verse. For this reason, object state is hidden & behaviors may be created to allow external objects access and change state values.

Another way to refer to encapsulation is 'information hiding'.

Encapsulation (Information Hiding)

"Information hiding - Wikipedia, the free encyclopedia" ( http://bit.ly/9yZwyY )