---
# System prepended metadata

title: Object Orient Programming-Course1 Week1
tags: [Coursera, OOP]

---

# Object Orient Programming-Course1 Week1
###### tags: `OOP` `Coursera`
<style>
.red {
  color: red;
}
</style>
<style>
.blue {
  color: blue;
}
</style>
<style>
.green {
  color: green;
}
</style>
# Four Design Principles
## 1 Abstraction
Abstraction is the idea of simplifying a concept in the problem domain to its essentials within some context.Abstraction allows you to better understand a concept by breaking it down into a simplified description that ignore unimportant details.

### Rule Of Least Astonishment
The abstraction captures the essential attributes and behavior for concept with no surprises and no definitions that fall beyond its scope.

**Context** or **Specific perspective** is critical when forming an abstraction.
Anything other than a concept's essential attributes and behaviors is irrelevant

Ex: Context is an **academic setting**
|.........|Essential               |Irrelevant|
|---------|------------------------|----------|
|Concept  |Student                 |Student   |
|Attribute|courses currently taking|has a cat |
|Behavior |Study, doing assignment |cooking   |

Ex: Context is **Modeling student from social perspective**
|.........|Essential                  |Irrelevant|
|---------|---------------------------|----------|
|Concept  |Student                    |Student   |
|Attribute|Student group belongs to   |has a cat |
|Behavior |Hold an activity for groups|studying  |

## 2 Encapsulation
### Three concept
1. Bundle attribute values or datas, behaviors or functions and manipulate those values together into a self-contained object.
2. Expose certain data and function
3. restrict access to certain data and functions to only within that object.

### Getter method
Getter methods are methods that retrieve data(usually private)
Typically named by "get + ${returned attribute name}"

### Setter method
Setter methods change data
Typically named by "set + ${target variable name}"

## 3 Decomposition
Decomposition is taking a whole thing and dividing it up into different parts. Or, on the flip side taking a bunch of separate parts with different functionalities, and combining them together to form a whole.

A **whole** might have a fixed or dynamic number of a certain type of **part**.
EX: Whole: refrigerator == decomposition==> Fixed part: one freezer, dynamic part: food item in it.

A **lifetime** of a part can be closely related or not so related to the whole.
EX: closely related: refrigerator to frezzer, car to engine(in most cases), not so related: refrigerator to food item, car to tire.

### three types of relationships found in decomposition
1. Association
2. Aggregation
3. Composition

### 3-1 Association
Association is **some** relationship.  This means that there is a loose relationship between two objects.  These objects may interact with each other for some time.

Ex:
```graphviz
digraph obj{
	node[shape=record];
	rankdir="BT";
	
	Person [label = "{<f0> Person|<f1> \n  |<f2> \n   }"];
	Airline [label = "{<f0> Airline|<f1> \n  |<f2> \n   }"];
	
	
	Airline->Person [dir="forward",arrowhead="none",arrowtail="normal",headlabel="0..*",taillabel=" 0..*"];
}
```
The instance means that 0 to multiple persons can associate to 0 to multiple airlines.
### 3-2 Aggregation
Aggregation is a <span class = "red">week</span> "**has a**" relationship where a whole has parts that belong to it.  The relationship is considered **week** as the parts can exist independently although it belongs to the whole.

EX:
```graphviz
digraph obj{
	node[shape=record];
	rankdir="BT";
	
	Airlines [label = "{<f0> Airlines|<f1> \n  |<f2> \n   }"];
	CrewMembers [label = "{<f0> CrewMembers|<f1> \n  |<f2> \n   }"];
	
	
	CrewMembers->Airlines [dir="forward",arrowhead="odiamond",arrowtail="normal",headlabel="0..*  ",taillabel="  0..*"];
}
```
For an airline, the crew members are it's crucial part.  We can state that airline **has a** crew members though it won't bother that crew members or airlines exist without each other.

### 3-3 Composition
Composition is an exclusive containment of parts, otherwise known as <span class = "red">strong</span> "**has a**" relationship.  The parts can't exist without the whole, and the whole can't exist without the parts as well.  **If the whole is destroyed, all its composition parts are too.**

EX: Rooms are parts of the house and should always exist with a house. Neither of them can't exist without each other.

```graphviz
digraph obj{
	node[shape=record];
	rankdir="BT";
	
	House [label = "{<f0> House|<f1> \n  |<f2> \n   }"];
	Room [label = "{<f0> Room|<f1> \n  |<f2> \n   }"];
	
	
	Room->House [dir="forward",arrowhead="diamond",arrowtail="normal",headlabel="  ",taillabel="  1..*"];
}
```

## 4 Generalization

Generalization may be defined as the technique of extracting the essential characteristics (these include attributes, properties and methods) from two or more subclasses and then combining them inside a generalized base class 

technique: inheritance
what should be generalized: repeated, common, shared characteristic

### 4-1 Generalization with Inheritence
**The arrow in Inheritence is always pointing upward**
#### 4-1-1 General Form of Inheritence
```graphviz
digraph obj{
	node[shape=record];
	rankdir="BT";
	
	Superclass [label = "{<f0> Superclass|<f1>Superclass attributes \n  |<f2>Superclass methods \n   }"];
	Subclass [label = "{<f0> Subclass|<f1>Subclass attributes \n  |<f2>Subclass methods \n   }"];
	
	
	Subclass->Superclass [dir="forward",arrowhead="onormal",arrowtail="normal",headlabel="  ",taillabel="  1..*"];
}
```

The super classes are generalized classes and subclasses are specialized classes.  Although <span class = "blue"> protected</span> attributes and methods in superclass are reachable for its subclasses, the subclasses should not take them as its attributes and methods.

#### 4-1-2 Example of Inheritence
EX:
```graphviz
digraph obj{
	node[shape=record];
	rankdir="BT";
	
	Animal [label = "{<f0> Animal|<f1>#numberOfLegs:int \n#numberOfTails:int\n#name:string  |<f2>+walk() \n+run()\n+eat()   }"];
	Dog [label = "{<f0> Dog|<f1>Subclass attributes \n  |<f2>Subclass methods \n   }"];
	
	
	Dog->Animal [dir="forward",arrowhead="onormal",arrowtail="normal",headlabel="  ",taillabel="  1..*"];
}
```

```java=
public abstract class Animal{
    protected int numberOfLegs;
    protected int numberOfTails;
    protected string name;
    
    public Animal(string _name, int _legs, int _tails)
    {
        this.numberOfLegs = legs;
        this.numberOfTails = _tails;
        this.name = _name;
    }
    
    public walk(){ ... }
    public run(){ ... }
    public eat(){ ... }
}

public class Dog extends Animail{
    public Dog(string _name, int _legs, int _tails){
        super(_name, _legs, _tails);  //explicit constructor: which means the constructor must be called. 
    }
    
    public walk(){
        System.out.printIn("I'm a dog walking"); // override
    }
}

```

Super class should have explicit constructor so that all the attribute can be initiaized when the class is instantiated.
A subclass's constructor should call its superclass's constructor if its superclass has explicit constructor.Otherwise, the superclass's attribute will not be appropriately initialized.

### 4-2 Generalization with Interface
* subtype:  A class denotes a type for its objects. The type signifies what these objects can do through public methods.   In modeling a problem, we may want to express subtyping relationships between two types. For example, we can have dog type as a subtype of animal type.

* Interface: An interface denote a subtype which only declares method signature, and no constructor, attribute or method body.
* When inherit an interface, all the methos signature in the interface must be explicity declared and implemented in the subclass.
#### 4-2-2 