There are a number of key terms that we must consider and fully understand when using classes. These are Fundimental, and these are
an easy way to remember this is A PIE (Yum)
Time to clear your head, think of nothing, now, im going to say a word, this word may not be some thing that would generally talk about but bare with me.
A Trainer You know what i mean, however you have an idea of a trainer, it may not be the same as the trainer i have in mind, size, colour, velcro or lace but you understand the idea of the trainer, the "Absraction" of the Trainer. You have seen many trainers "Abstract" the understand them. So the absration of the product is to focus on the essential qualities of the item and not the specifics of an example, therefore we get of the irelvant information.
So lets look at the absration of a class, we can use the example of an back account. Lets suppose that we have two bank accounts as below,
+-----------+ | Bank Acc | +-----------+ | Account No| | Balance | | Date Open | | Acc Type | +-----------+ +-----------+ +-----------+ | Ab002 | | AB003 | | £-250 | | £2000 | | 12/12/69 | | 25/06/12 | | Checking | | Savings | +-----------+ +-----------+ Joe John
The use of encapsulation in OOP is best covered by first understanding of the word encapsulation. If you think of the word encapsulate this refers to a container this could be a bowl, a medical capsule, a bottle, so what do these do?, they not only keep the components within the capsule together but they also protect them. Takes the attributes and the behaviours and puts them in to a unit/class.
+-----------+ | Bank Acc | +-----------+ | Account No| | Balance | | Date Open | ← Attributes | Acc Type | +-----------+ | Open () | | Close () | | Deposit ()| ← Behaviours | Withdraw()| +-----------+
So within these classes we may wish to hide the data, this is known as "information hiding/data hiding" the idea is that the object should NOT reveal any information about itself except only that what is necesary to enable other parts of the application to work.
Example;
+--------------+ | Player | +--------------+ | Player ID | | Name | | Date spawned | ← Attributes | Lives | +--------------+ | Alive () | | spawn () | | lives () | ← Behaviours | Power up () | +--------------+
We dont want any other part of the application to reach inside this object and change the lives of the player without going through the lives behaviour. These behaviours are designed to reduce the lives of the player if they are hit by an enmy. So with data/information hiding we can hide that attribute which means we can control access to it so that it is only accessable from with within that object itself.
This is commonly refered to a "Black Boxing"
The use of inheritance is widely use accross a number of coding language and the concept is based around efficency, and this is based on the reuse of coding. So, where a new class is required and is based on an existing class. Lets refer to an example to assist you in understanding this.
+--------------+ | Player | +--------------+ | Player ID | | Name | | Date spawned | ← Attributes | Lives | +--------------+ | Alive () | | spawn () | | lives () | ← Behaviours | Power up () | +--------------+
You have in this class set up your understanding to the needs of the characters in the game that you wish to create however at a later date you understand the you will need to introduce enimies and heros, these classes will have attributes that are identical to those that are created in the player area, so, why would we repeat these? The only difference is that they may have some additional attributes. So we wouldnt add these to the player class as this is not required, we are trying to use "Abstraction" and remove all un-required information and only have the essentials.
+--------------+ | Character | ← (Parent Class or Super Class) +--------------+ | Player ID | | Name | | Date spawned | +--------------+ | Alive () | | spawn () | +--------------+ ↑ Inherits from +--------------+ +--------------+ | Hero | | Enemy | ← (Child Class or Sub Class) +--------------+ +--------------+ | Lives | | type | +--------------+ +--------------+ | lives () | | lives () | | Power up () | +--------------+ +--------------+
When we use the use of inheritance in UML we must ensure that we use the correct symbols, these are hollow directional arrows
The definition of Poloymorphism in OOD is "many forms" this allows a class to automatically do the correct behaviours even it takes one of many forms. The area of Polymorphism can be a complex area and the best way to understand how it works is by looking at the addtion sign (+), if we are adding the contents of A + B as integers we could end up with 5 + 6 = 11, however if we consider what happens with strings is that it will concatenate them therefore presenting "Hello + World" as HelloWorld. So both are doing the correct behaviour but different behaviours.
Lets look in to linking this our classes. In this instance i will be looking at using the example of a bank account. We all have bank accounts however these can be different.
+-----------+ | Bank Acc | +-----------+ | Account No| | Balance | | Date Open | | Acc Type | +-----------+ | deposit ()| | Withdraw()| +-----------+ ↗ ↑ ↖ +-----------+ +-----------+ +-----------+ | Check Acc | |Saving Acc | |Invest Acc | +-----------+ +-----------+ +-----------+ |All from | |All from | |All from | | (Bank Acc)| | (Bank Acc)| | (Bank Acc)| | Last Check| |Interest | | accountRep| +-----------+ +-----------+ +-----------+ | | | | |withdraw ()| ← Overriding | | | | | | +-----------+ +-----------+ +-----------+
So if we look at the three accounts these all are sub classes of the parent class of Bank Acc, however these are all specialised but inherit from parent.
But lets look at when the investment account has money widthdrawn from it, there are penalties that are applied which means that the orriginal widthdraw behaviour will need to be different, so currently the nature of the "Inheritance" of the original widthdrawal will need to overriden and this is done by adding it to the subclass.
So we have in this example polymorphised the withdraw behaviour so that we can do the right action at the right time.
http://www.visual-paradigm.com/VPGallery/diagrams/Sequence.html
Review the video using the following link VIDEO and create notes to support your controlled assessments. Fill in the Gaps!
Links to Learning Outcomes |
Links to Assessment criteria |
|
---|---|---|
Anonymous Assessment - Learners assess an anonymous piece of work containing deliberate mistakes against given success criteria.