1. IN 076 Pola Desain Perangkat Lunak Dosen: Hapnes Toba (hapnestoba@gmail.com)hapnestoba@gmail.com Oscar Karnalim (oscar.karnalim@gmail.com)oscar.karnalim@gmail.com Asisten: Lucky Christiawan Teori: Jumat 13.00 - 15.30 Lab ADV 1 Praktikum: Jumat 15.30 – 17.30 Lab ADV 1

2. Referensi Pendukung 1.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

3. 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 1 Pertemuan 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)

4. 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 3 Pertemuan x (Isra Miraj) 6 Mei 2016 Libur Pertemuan 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)

5. 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

6. 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

7. Course Objectives Design 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.

8. Review of Object-Oriented Principles What does OO Design mean?

9. Three pillars of OO Design Encapsulation InheritancePolymorphism OO Design Design Pattern Best practices

10. Group Discussion (Collaborative Learning) Encapsulation InheritancePolymorphism OO Design For each concept (Group 1 – 3) 1.Define the concept 2.Find an UML Class Diagram as an example 3.Find the appropriate OOP code for the example Group 4 1.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?

11. Looking behind the object Encapsulation

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

13. 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

14. Encapsulation Example Using Java 5.0 Using Eclipse 3.1 Using a “Medication” class object private String: Name private int: Dosage private String: Route private 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 setters Name Dosage Route Form getName getDosage getRoute getForm setName setDosage setRoute setForm

15. Inheritance Dealing with Object Hierarchies

16. Inheritance Facilitates code re-use Organizes objects in a IS-A hierarchy Person age name Student major graduationyear Employee type

17. Polymorphism Many faces of an Object

18. 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 object display object pdf object print object display object Word object print object display object new object print object display object

19. A simple example* animal type eats sound herbivore type eats sound carnivore type eats sound omnivore type eats sound elephant type eats sound lion type eats sound bear type eats sound Does it make sense to instantiate these classes? *Adapted from Head First Java, O’Reilly Press

20. 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.

21. Role of Interfaces How does one deal with multiple inheritance?

22. Multiple Inheritance animal eats sound cat eats sound dog eats sound hippo eats sound pet Rollover?

23. Problem with multiple inheritance* Digirecord burn() DVDBurner burn() CDBurner burn() ComboBurner burn() *Adapted from Head First Java, O’Reilly Press

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

25. Multiple Inheritance – make Pet class an interface animal eats sound cat eats sound dog eats sound hippo eats sound pet Rollover?

26. Introduction to Design Patterns Chapter 1 Strategy Pattern

27. 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

28. Simple Simulation of Duck behavior Duck quack() swim() display() // other duck methods MallardDuck display() // looks like mallard RedheadDuck display() // looks like redhead Other duck types

29. What if we want to simulate flying ducks? Duck quack() swim() display() fly() // other duck methods MallardDuck display() // looks like mallard RedheadDuck display() // looks like redhead Other duck types

30. Tradeoffs in use of inheritance and maintenance Duck quack() swim() display() fly() // other duck methods MallardDuck display() // looks like mallard RubberDuck quack() //overridden to squeak display() // looks like rubberduck fly() // override to do nothing RedheadDuck display() // looks like redhead One could override the fly method to the appropriate thing – just as the quack method below.

31. Example complicated: add a wooden decoy ducks to the mix DecoyDuck quack(){ // override to do nothing } display() // display decoy duck fly (){ //override to do nothing } Inheritance is not always the right answer. Every new class that inherits unwanted behavior needs to be overridden. How about using interfaces instead?

32. 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

33. 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….

35. Design Principle Identify 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.

36. In the Duck simulation context… Duck Behaviors Parts that vary Parts that stay the same

37. Design Principle Program to an interface, not to an implementation. Really means program to a super type.

38. Program to an interface Programming to an implementation Dog d = new Dog(); d.bark(); Programming to an interface Animal animal = new Dog(); animal.makesound();

39. Duck simulation recast using the new approach MallardDuck display() RedHeadDuck display() RubberDuck display() DecoyDuck display() Duck FlyBehavior: flyBehavior QuackBehavior: quackBehavior performQuack() performFly() setFlyBehavior() setQuackBehavior() swim() display() > FlyBehavior fly() FlyWithWings fly() // implements duck flying FlyNoWay fly() // do nothing – Can’t fly > QuackBehavior quack() Quack quack() // implements duck quacking Squeak quack() // implements squeak Mutequack quack() // do nothing

40. 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

41. Design Principle Favor composition over inheritance HAS-A (behavior) can be better than IS-A Allows changing behavior at run time

42. 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.

43. 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 > WeaponBehavior useWeapon() Queen fight() King fight() Knight fight() Bishop fight() SpearBehavior useWeapon() //implements fight with // a spear setWeapon(WeaponBehavior w){ this.weapon = w; }

44. 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 > WeaponBehavior useWeapon() Queen fight() King fight() Knight fight() Bishop fight() SpearBehavior useWeapon() //implements fight with // a spear setWeapon(WeaponBehavior w){ this.weapon = w; } Abstract

45. 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 > WeaponBehavior useWeapon() Queen fight() King fight() Knight fight() Bishop fight() SpearBehavior useWeapon() //implements fight with // a spear setWeapon(WeaponBehavior w){ this.weapon = w; } Abstract Behavior Interface

46. 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 > WeaponBehavior useWeapon() Queen fight() King fight() Knight fight() Bishop fight() SpearBehavior useWeapon() //implements fight with // a spear setWeapon(WeaponBehavior w){ this.weapon = w; } Abstract Behavior Interface

47. KnifeBehavior useWeapon() //implements cutting with // a knife BowAndArrowBehavior useWeapon() //implements fight with // bow and arrows AxeBehavior useWeapon() //implements fight with // an axe > WeaponBehavior useWeapon() Queen fight() King fight() Knight fight() Bishop fight() SpearBehavior useWeapon() //implements fight with // a spear Abstract Behavior Interface Character WeaponBehavior weapon; fight(); setWeapon(WeaponBehavior w){ this.weapon = w; }

48. 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