IN 076 Pola Desain Perangkat Lunak Dosen: Hapnes Toba Oscar Karnalim

IN 076 Pola Desain

Perangkat LunakDosen :

Hapnes Toba ([email protected])Oscar Karnalim ([email protected])

Asisten :Lucky Christiawan

Teori : Jumat 13.00 - 15.30 Lab ADV 1Praktikum : Jumat 15.30 – 17.30 Lab ADV 1

mailto:[email protected]

mailto:[email protected]

Referensi Pendukung1. Eric Freeman & Elisabeth Freeman; Head First Design Patterns; O’Reilly; 2004

2. Allen Holub; Holub on Patterns: Learning Design Patterns by Looking at Code;

Apress; 2004

3. Christopher G. Lasater; Design Patterns; Wordware Publishing Inc.; 2007

4. Erich Gamma, et.al.; Design Patterns: Elements of Reusable Object Oriented

Software; Addison-Wesley Intl.; 1994

5. James W. Cooper; Introduction to Design Patterns in C#, IBM TJ Watson Research

Center; 2002

6. Jason McDonald; Design Patterns, DZone Refcards; www.dzone.com; 2008

7. Metsker, Steven John, William C. Wake, Design Patterns in Java 2nd ed., Addison-

Wesley Professional, 2006.

8. Metsker, Steven John, Design Patterns in C#, Addison-Wesley Professional, 2004.

9. Steve Holzner, PhD.; Design Patterns for Dummies; Wiley Publishing, Inc.; 2006

10. http://www.dofactory.com

11. etc

Rencana Pertemuan (1)Pertemuan 1 12 Februari 2016 Pengenalan, Review PBO, Strategy (Ch. 1)Pertemuan 2 19 Februari 2016 Observer (Ch. 2), Decorator (Ch. 3)Pertemuan 3 26 Februari 2016 Factory (Ch. 4)Pertemuan 4 4 Maret 2016 Quis 1Pertemuan 5 11 Maret 2016 Command (Ch. 6)

Pertemuan 6 18 Maret 2016 Template (Ch. 8), Singleton (Ch. 5)Review Materi (1-6)

Pertemuan x (Jumat Agung) 25 Maret 2016 Quis 2 + Kuis Besar (take home)Ujian Tengah Semester 28 Maret - 8 April 2016 UTS (Bahan pertemuan 1-6)

Rencana Pertemuan (2)Pertemuan 7 15 April 2016 Iterator & Composite (Ch. 9), State (Ch. 10)Pertemuan 8 22 April 2016 Adaptor & Facade (Ch. 7)Pertemuan 9 29 April 2016 Quis 3Pertemuan x (Isra Miraj) 6 Mei 2016 LiburPertemuan 10 13 Mei 2016 Proxy (Ch. 11), Compound (Ch. 12)Pertemuan 11 20 Mei 2016 Patterns in the real world (Ch. 13)

Pertemuan 12 27 Mei 2016

Left over patterns (Ch. 14): Bridge, Builder, Chain of Responsibility, Flyweight, Interpreter, Mediator, Momento, Prototype, Visitor; Review Materi (7-12)Quis 4 + Kuis Besar (take home)

Ujian Akhir Semester 30 Mei - 10 Juni 2016 UAS (Bahan pertemuan 7-12)

Penilaian• UTS (30% dari total) – jika hadir

• Rata-rata kuis (2x) : 15%• Rata-rata keaktifan kelas : 15%• Kuis besar : 20%• Soal UTS : 50%

• UAS (30% dari total) – jika hadir• Rata-rata kuis (2x) : 15%• Rata-rata keaktifan kelas : 15%• Kuis besar : 20%• Soal UTS : 50%

• KAT (40%) – tugas-tugas per pertemuan• Sesi praktikum

Organisasi Kelas• Asisten• Mengawasi absensi, pengumpulan tugas dan praktikum

• Dosen• Pemberian materi dan tugas• Menilai tugas harian, kuis, praktikum dan ujian

• Situasi kelas• Keterlambatan max. 15 menit boleh masuk, tidak

absen• No ringtones Tidak ada absensi susulan• Tugas di-upload sesuai pemberitahuan di kelas

Course ObjectivesDesign patterns are programming best practices. Learning them makes one an effective and efficient developer of software

solutions. Starting with introductory background on object-oriented principles, this

course seeks to provide an overview of some of the most commonly and widely used design patterns.

The course is hands on and involves developing solutions that use these patterns.

Review of Object-OrientedPrinciplesWhat does OO Design mean?

Three pillars of OO Design

Encapsulation Inheritance Polymorphism

OO Design

structural

creational

Design Pattern

Best practices

Group Discussion(Collaborative Learning)

Encapsulation Inheritance Polymorphism

OO Design

For each concept (Group 1 – 3)1. Define the concept2. Find an UML Class Diagram as an example3. Find the appropriate OOP code for the example

Group 41. What is the difference between a class and an object?2. Give example, what is an abstract class?3. Give example, what is an interface?

Looking behind the object

Encapsulation

Encapsulation• Hide the data – make data elements private• Provide access to data using getters and setters – make these public

What is the big deal here?• Setters can ensure that data fields don’t get set with inappropriate

value• You can change the implementation without impacting people who

are using your object

Encapsulation Example• Using Java 5.0• Using Eclipse 3.1• Using a “Medication” class object

private String: Nameprivate int: Dosageprivate String: Routeprivate String: Form

Medication

public String getName()public int getDosage()public String getRoute()public String getForm()

public void setName()public void setDosage()public void setRoute()public void getForm()

getters

settersName

DosageRouteForm

getN

ame

getDosage getRoute getForm

setName

setDosage setRoute

setF

orm

InheritanceDealing with Object Hierarchies

Inheritance• Facilitates code re-use• Organizes objects in a IS-A hierarchy

Person

agename

Student

majorgraduationyear

Employee

type

PolymorphismMany faces of an Object

Polymorphism• Ability to communicate to objects that don’t even exist when initial

design was created!• Use methods defined in parent class on child class

Object 1

print objectdisplay object

pdf object


Word object


new object


A simple example*animal

typeeatssound

herbivore

typeeatssound

carnivore

typeeatssound

omnivore

typeeatssound

elephant

typeeatssound

lion

typeeatssound

bear

typeeatssound

Does it makesense to

instantiate these classes?

*Adapted from Head First Java, O’Reilly Press

Abstract Classes• When it does not make sense to instantiate a particular class, but it

makes sense to define them for the purpose of organization, use an “Abstract” class.• Abstract class cannot be instantiated – they can only be “extended”• Abstract classes can have abstract methods as well.. These methods

have to be implemented in the concrete classes.

Role of InterfacesHow does one deal with multiple inheritance?

Multiple Inheritance

animal

eatssound

cat

eatssound

dog

eatssound

hippo

eatssound

pet

Rollover?

Problem with multiple inheritance*Digirecord

burn()

DVDBurner

burn()

CDBurner

burn()

ComboBurner

burn()

*Adapted from Head First Java, O’Reilly Press

Java approach• Use Interfaces• Classes can “extend” classes and they can “implement” interfaces.

Multiple Inheritance – make Pet class an interface

animal

eatssound

cat

eatssound

dog

eatssound

hippo

eatssound

pet

Rollover?

Introduction to Design Patterns

Chapter 1Strategy Pattern

Goals for this week• Learn how to exploit and gain experience of others• Examine the benefits of design pattern• Learn one specific pattern: Strategy pattern

Simple Simulation of Duck behaviorDuck

quack()swim()display()// other duck methods

MallardDuck

display()// looks like mallard

RedheadDuck

display()// looks like redhead

Other ducktypes

What if we want to simulate flying ducks?

Duck

quack()swim()display()fly()// other duck methods

MallardDuck


RedheadDuck


Other ducktypes

Tradeoffs in use of inheritance and maintenance

Duck

quack()swim()display()fly()// other duck methods

MallardDuck


RubberDuck

quack()//overridden to squeakdisplay()// looks like rubberduckfly()// override to do nothing

RedheadDuck


One could override thefly method to the appropriatething – just as the quackmethod below.

Example complicated: add a wooden decoy ducks to the mix

DecoyDuck

quack(){// override to do nothing}display()// display decoy duckfly (){//override to do nothing}

Inheritance is not always the rightanswer. Every new class that inheritsunwanted behavior needs to beoverridden.

How about using interfaces instead?

Duck simulation recast using interfaces.

Duck

swim()display()// other duck methods

MallardDuck

display()fly()quack()

Quackable

quack()

Flyable

fly()

RedheadDuck

display()fly()quack()

RubberDuck

display()quack()

DecoyDuck

display()

Interfaces

Pros and cons• Not all inherited methods make sense for all

subclasses – hence inheritance is not the right answer• But by defining interfaces, every class that needs to

support that interface needs to implement that functionality… destroys code reuse!• So if you want to change the behavior defined by

interfaces, every class that implements that behavior may potentially be impacted

And….

Design PrincipleIdentify the aspects of your application that vary and separate them

from what stays the same.OR

Take the parts that vary and encapsulate them, so that later you can alter or extend the parts that vary without affecting those that don’t.

In the Duck simulation context…

DuckBehaviors

Parts that varyParts that stay the same

Design Principle

• Program to an interface, not to an implementation.

• Really means program to a super type.

Program to an interface• Programming to an implementation

Dog d = new Dog();d.bark();

• Programming to an interfaceAnimal animal = new Dog();animal.makesound();

Duck simulation recast using the new approach

MallardDuck

display()

RedHeadDuck

display()

RubberDuck

display()

DecoyDuck

display()

Duck

FlyBehavior: flyBehaviorQuackBehavior: quackBehavior

performQuack()performFly()setFlyBehavior()setQuackBehavior()swim()display()

<<interface>>FlyBehavior

fly()

FlyWithWingsfly()// implements duckflying

FlyNoWayfly()// do nothing –Can’t fly

<<interface>>QuackBehaviorquack()

Quackquack()// implements duckquacking

Squeakquack()// implements squeak

Mutequackquack()// do nothing

Rationale for design patterns• Shared pattern vocabularies are powerful• Patterns allow you to say more with less• Reusing tried and tested methods• Focus is on developing flexible, maintainable programs

Design Principle

• Favor composition over inheritance

• HAS-A (behavior) can be better than IS-A• Allows changing behavior at run time

The strategy pattern

• The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable.

• Strategy lets the algorithm vary independently from clients that use it.

Character

WeaponBehavior weapon;

fight();

KnifeBehavior

useWeapon()//implements cutting with// a knife

BowAndArrowBehavior

useWeapon()//implements fight with// bow and arrows

AxeBehavior

useWeapon()//implements fight with// an axe

<<interface>>WeaponBehavior

useWeapon()

Queen

fight()

King

fight()Knight

fight()

Bishop

fight()

SpearBehavior

useWeapon()//implements fight with// a spear

setWeapon(WeaponBehavior w){this.weapon = w;

}

Character


fight(); KnifeBehavior


BowAndArrowBehavior


AxeBehavior



useWeapon()

Queen

fight()

King

fight()

Knight

fight()

Bishop

fight()

SpearBehavior



}

Abstract

Character


fight();

KnifeBehavior


BowAndArrowBehavior


AxeBehavior



useWeapon()

Queen

fight()

King

fight()

Knight

fight()

Bishop

fight()

SpearBehavior



}

Abstract Behavior Interface

Character


fight();

KnifeBehavior


BowAndArrowBehavior


AxeBehavior



useWeapon()

Queen

fight()

King

fight()

Knight

fight()

Bishop

fight() SpearBehavior



}

Abstract Behavior Interface

KnifeBehavior


BowAndArrowBehavior


AxeBehavior



useWeapon()

Queen

fight()

King

fight()

Knight

fight()

Bishop

fight()

SpearBehavior


AbstractBehavior Interface

Character


fight();setWeapon(WeaponBehavior w){ this.weapon = w;}

Challenge: next week in class discussion• Implement the weapon class from previous slide (individual)• Upload via cls.maranatha.edu • Due Fri, 19 Feb 2016, 12:00

Documents

IN 076 Pola Desain Perangkat Lunak Dosen: Hapnes Toba Oscar Karnalim