Object-Orientated Design

72
Object-Orientated Design Damian Gordon

Transcript of Object-Orientated Design

Page 1: Object-Orientated Design

Object-Orientated DesignDamian Gordon

Page 2: Object-Orientated Design

Object Orientation

• An object is any tangible thing we can see touch and manipulate.

Page 3: Object-Orientated Design

Object Orientation

Page 4: Object-Orientated Design

Object Orientation

• Software objects are models are similar in the sense that they have certain features and can do certain things.

Page 5: Object-Orientated Design

Object

Page 6: Object-Orientated Design

Features

Behaviours

Page 7: Object-Orientated Design

Attributes

Methods

Page 8: Object-Orientated Design

Attributes

Methods

Attributes:A Collection of

variables

Page 9: Object-Orientated Design

Attributes

Methods

Attributes:A Collection of

variables

Methods:A Collection of

procedures

Page 10: Object-Orientated Design

Hair Colour

DogEye ColourHeightWeight

Length

Lie Down( ) Fetch( )

Sit( )Bark( )

Roll Over( )

Page 11: Object-Orientated Design

Attributes

Methods

Encapsulation

Page 12: Object-Orientated Design

Object Orientation

• To create an object what we typically do is first create the general class that a specific object comes from, and then we create a specific object of that class.

• For example, if a want to model a specific dog, first create the general CLASS of DOG, and then create a specific instance of that class, an OBJECT, called TINY the dog.

Page 13: Object-Orientated Design

Tiny

Page 14: Object-Orientated Design

Object Orientation

• Sometimes it’s easier to model things as an OBJECT, but often it’s easier to model a collection of things as a CLASS, and then create instances (‘OBJECTS’) of that CLASS.

• We can use UML (the Unified Modelling Language) to model Object-Orientated programs, and one modelling tool within UML is called a CLASS DIAGRAM.

Page 15: Object-Orientated Design

Object Orientation

• Let’s imagine we wanted to create a CLASS DIAGRAM for the following scenario:

– We work in a greengrocer, we sell APPLES and ORANGES; APPLES are stored in BARRELS and ORANGES are stored in BASKETS.

Page 16: Object-Orientated Design

Object Orientation

• APPLES are stored in BARRELS and ORANGES are stored in BASKETS.

Page 17: Object-Orientated Design

Object Orientation

• APPLES are stored in BARRELS and ORANGES are stored in BASKETS.

Apple

Page 18: Object-Orientated Design

Object Orientation

• APPLES are stored in BARRELS and ORANGES are stored in BASKETS.

Apple Barrel

Page 19: Object-Orientated Design

Object Orientation

• APPLES are stored in BARRELS and ORANGES are stored in BASKETS.

Apple Barrel

Orange

Page 20: Object-Orientated Design

Object Orientation

• APPLES are stored in BARRELS and ORANGES are stored in BASKETS.

Apple Barrel

Orange Basket

Page 21: Object-Orientated Design

Object Orientation

• Let’s add in more rules to the scenario:

– Many APPLES are stored in one BARREL and many ORANGES are stored in one BASKET.

Page 22: Object-Orientated Design

Object Orientation

• Many APPLES are stored in one BARREL and many ORANGES are stored in one BASKET.

Apple Barrel

Orange Basket

*

* 1

1

Page 23: Object-Orientated Design

Object Orientation

• Many APPLES are stored in one BARREL and many ORANGES are stored in one BASKET.

Apple Barrel

Orange Basket

*

* 1

1

go in >

go in >

Page 24: Object-Orientated Design

Object Orientation

• Let’s add some attributes:

Page 25: Object-Orientated Design

Object Orientation

Apple Barrel

Orange Basket

*

* 1

1

go in >

go in >

+colour+weight +size

+weight+orchard

+date_picked+location

Page 26: Object-Orientated Design

Object Orientation

Apple Barrel

Orange Basket

*

* 1

1

go in >

go in >

+colour: string+weight: float +size: int

+weight: float+orchard: string

+date_picked: date+location: string

Page 27: Object-Orientated Design

Object OrientationApple Barrel

Orange Basket

*

* 1

1

go in >

go in >

+colour: string+weight: float+barrel: Barrel

+size: int+apples: list

+weight: float+orchard: string

+date_picked: date+basket: Basket

+location: string+oranges: list

Page 28: Object-Orientated Design

Object Orientation

• Now let’s add some methods:

Page 29: Object-Orientated Design

Object Orientation

Apple Barrel

* 1go in >

+colour: string+weight: float+barrel: Barrel

+size: int+apples: list

+pick(backet: Basket)+squeeze( ): juice

+sell(cust: Customer)+discard( )

Page 30: Object-Orientated Design

Object Orientation

Orange Basket* 1

go in >

+weight: float+orchard: string

+date_picked: date+basket: Basket

+location: string+oranges: list

+pick(backet: Basket)+squeeze( ): juice

+sell(cust: Customer)+discard( )

Page 31: Object-Orientated Design

Information Hiding

Page 32: Object-Orientated Design

Object

Page 33: Object-Orientated Design

Attributes

Methods

Page 34: Object-Orientated Design

Attributes

Methods

Encapsulation

Page 35: Object-Orientated Design

Hair Colour

DogEye ColourHeight Weight

Length

Lie Down( ) Fetch( )

Sit( )Bark( )

Roll Over( )

Page 36: Object-Orientated Design

Hair ColourEye ColourHeight Weight

Length

Lie Down( ) Fetch( )

Sit( )Bark( )

Roll Over( )

OTHER CLASSES

InformationHiding

Page 37: Object-Orientated Design

Object Orientation

• An OBJECT is made up of ATTRIBUTES and METHODS. Some of these can be private to the CLASS, and some can be public and used by other classes.

• The public elements (ATTRIBUTES and METHODS) of the CLASS are referred to as the INTERFACE (or PUBLIC INTERFACE).

Page 38: Object-Orientated Design

Hair ColourEye ColourHeight Weight

Length

Lie Down( ) Fetch( )

Sit( )Bark( )

Roll Over( )

OTHER CLASSES

Page 39: Object-Orientated Design

Hair ColourEye ColourHeight Weight

Length

Lie Down( ) Fetch( )

Sit( )Bark( )

Roll Over( )

OTHER CLASSES

PublicInterface

Page 40: Object-Orientated Design

Object Orientation

• A common real-world example is the television. Our interface to the television is the remote control.

• Each button on the remote control represents a method that can be called on the television object.

Page 41: Object-Orientated Design

Object Orientation

• The public interface is very important, we have to design it carefully, because it can be difficult to change in the future, and changing it will cause problems for any client objects that are calling it.

• We can change the internals as much as we like (e.g. to make it more efficient, or to access data over the network as well as locally) and the client objects will still be able to talk to it, unmodified, using the public interface.

Page 42: Object-Orientated Design

Abstraction

Page 43: Object-Orientated Design

Object Orientation

• ABSTRACTION means dealing with the level of detail that is most appropriate to a given task.

• For example, a DRIVER of a car needs to interact with steering, gas pedal, and brakes. The workings of the motor, drive train, and brake subsystem don't matter to the driver. A MECHANIC, on the other hand, works at a different level of abstraction, tuning the engine and bleeding the breaks.

Page 44: Object-Orientated Design

Object Orientation

Driver Car

drives > +brakes+accelerator

+steer( )+change_gears( )+apply_brakes( )

Mechanic Car

fixes >+disc_brakes

+engine+transmission

+adjust_breaks( )+change_oil( )

Page 45: Object-Orientated Design

COMPOSITION

Page 46: Object-Orientated Design

Object Orientation

• COMPOSITION is the act of collecting several objects together to create a new one.

• Composition is usually a good choice when one object is part of another object.

Page 47: Object-Orientated Design
Page 48: Object-Orientated Design

Object Orientation

• A car is composed of an engine, transmission, starter, headlights, and windshield, among numerous other parts.

• The engine, in turn, is composed of pistons, a crank shaft, and valves. In this example, composition is a good way to provide levels of abstraction.

• The car object can provide the interface required by a driver, while also providing access to its component parts, which offers the deeper level of abstraction suitable for a mechanic.

Page 49: Object-Orientated Design
Page 50: Object-Orientated Design

Object Orientation

• Let’s try modelling computer chess as a CLASS DIAGRAM:

Page 51: Object-Orientated Design

Object Orientation

• Let’s try modelling computer chess as a CLASS DIAGRAM:

Player Chess Set

2 1make_move >

Page 52: Object-Orientated Design

Object Orientation

• The diagram shows that exactly two players can interact with one chess set.

• This also indicates that any one player can be playing with only one chess set at a time.

Page 53: Object-Orientated Design

Object Orientation

• Just for fun, let’s try to model at an object level instead of at a class level.

• For this we use an OBJECT DIAGRAM.

Page 54: Object-Orientated Design

Player

Class

Page 55: Object-Orientated Design

Player

Player 1

Player 2

Class Objects

Page 56: Object-Orientated Design

Object Orientation

• This is an OBJECT DIAGRAM (or INSTANCE DIAGRAM):

Chess Set

Player 1

Player 2make_move

make_move

Page 57: Object-Orientated Design

Object Orientation

• An OBJECT DIAGRAM or INSTANCE DIAGRAM describes the system at a specific state in time, and is describing specific instances of objects, not the interaction between classes.

Page 58: Object-Orientated Design

Object Orientation

• Lets return to the class diagram:

Page 59: Object-Orientated Design

Object Orientation

• Lets return to the class diagram:

Player Chess Set

2 1make_move >

Page 60: Object-Orientated Design

Object Orientation

• Thinking about the composition of a Chess Set we know it’s made up of a board and 32 pieces.

• The board further comprises 64 positions.

• The composition relationship is represented in UML as a solid diamond.

Page 61: Object-Orientated Design

Object Orientation

Player

Chess Set

2

1

make_move >

Page 62: Object-Orientated Design

Object Orientation

Player

Chess Set

2

1

make_move >

Piece

32

1

Page 63: Object-Orientated Design

Object Orientation

Player

Chess Set

2

1

make_move >

Piece

32

Board1

1 1

Page 64: Object-Orientated Design

Object Orientation

Player

Chess Set

2

1

make_move >

Piece

32

Board1

1 1

Position

64

1

Page 65: Object-Orientated Design

Object Orientation

• Finally let’s add some attributes to the class diagram:

Page 66: Object-Orientated Design

Object Orientation

Player

Chess Set

2

1

make_move >

Piece

32Board

1

1 1

Position

64

1

+pieces: list+board: Board

+chess_set: ChessSet+positions: Position+chess_set: ChessSet

+chess_board: Board

Page 67: Object-Orientated Design

INHERITANCE

Page 68: Object-Orientated Design

Object Orientation

• INHERITANCE is the last type of relationship we’ll look at.

• Inheritance is simple, it means that one class can inherit attributes and methods from another class.

• So often we look for classes that have a lot in common, and create a single class with those commonalities, and use that class to give those features to all the other classes.

Page 69: Object-Orientated Design

Object Orientation

• Let’s look at an example of chess pieces:

• We know that all PIECES are part of a CHESS_SET and have a COLOUR (so they should be in our BASE CLASS).

• Each piece has a different SHAPE attribute and a different MOVE method to move the piece to a new position on the board at each turn.

Page 70: Object-Orientated Design

Object Orientation

Piece+chess_set: ChessSet

+colour: Sting Pawn+shape: String

+move(Board)

Queen+shape: String

+move(Board)

Castle+shape: String

+move(Board)

Bishop+shape: String

+move(Board)

Knight+shape: String

+move(Board)

King+shape: String

+move(Board)

Page 71: Object-Orientated Design

Object Orientation

• Inheritance also gives us POLYMORPHISM.

• Polymorphism is the ability to treat a class differently depending on which subclass is implemented.

• All the board has to do is call the move() method of a given piece, and the proper subclass will take care of moving it as a Knight or a Pawn.

Page 72: Object-Orientated Design

etc.