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.

Inheritance

Classes contain state & behaviour - things they have & things they do. Just as humans inherit certain states & behaviours from their parents, so too can classes.

Often referred to as a Parent-Child relationship. Other names include:

Parent | Superclass | Base class | Generalisation

Child | Subclass | Derived class | Specialisation

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 )

Parameters

The inputs required by a behavior are often called Parameters and like state, a data type is required in the definition of a parameter.

The format for representing parameters in a behavior:  

BehaviorName(Parameter: DataType)

The format for representing a behavior that has no parameters:  

BehaviorName()

Class example:

The Login behavior of a class called Player class may look like this:

Login(Password: String)

The parenthesis (brackets) which follow the name of the behavior are used to identify any parameters that are required for the behavior to function. In this case of the Login behavior, a parameter called Password which has a data type of String is required by the behavior for it to function. In other words, the Player class has a Login function but it needs a String password to execute.

The Logout behavior of the Player class looks like this:

Logout()

You will notice that the parenthesis for this behavior are empty. This behavior does not require any parameters to execute.

There are two behaviors in the Player class which are responsible for increasing and decreasing the Player class Health state:

IncreaseHealth(Increase: Integer)
DecreaseHealth(Decrease: Integer)

Both of these behaviors require an Integer (whole number) parameter. In other words, these behaviors need to know how much to increase or decrease the Player Health state. As you might imagine, a Player may incur varying amounts of damage or gain varying amounts of health depending on the various interactions within game play.

What Is an Object?

From http://download.oracle.com/javase/tutorial/java/concepts/object.html

"Objects are key to understanding object-oriented technology. Look around right now and you'll find many examples of real-world objects: your dog, your desk, your television set, your bicycle.

Real-world objects share two characteristics: They all have state and behavior. Dogs have state (name, color, breed, hungry) and behavior (barking, fetching, wagging tail). Bicycles also have state (current gear, current pedal cadence, current speed) and behavior (changing gear, changing pedal cadence, applying brakes). Identifying the state and behavior for real-world objects is a great way to begin thinking in terms of object-oriented programming." Read more >>>

Programming State

An object state (things the object has - attributes like Name, Price, Damage) is simply a value that needs to be stored in memory. Object states are implemented as constants or variables.

Note: Other terms for state include property, attribute and data member.

---

Constant
When we need to store a value that does not change, we declare a constant.

Code eg: Constant Declaration

Private Const strThisConstant As String = "Something"

---

        Variable
         When we need to store a value that will need to change, we use a variable.

Code eg: Variable Declaration

Private strThisVariable As String = "Something"