1: software design fundamentalssoftware design and development_pon’2013 | 3 1.6 data structure...

Software Design and Development_Pon’2013 | 1

1: Software Design Fundamentals

1. Design Fundamentals 1.1 Abstraction

เปนการคดแยกรายละเอยดของปญหาออกเปนระดบทชดเจน ม 2 ประเภท คอ (1) Procedural Abstraction (เชงกระบวนการท างาน) คอ ล าดบค าสงทมหนาทเฉพาะและจ ากด เชน ทประตทางออกโรงภาพยนตรตางๆ มค าวา “Exit” หมายถง

ทางออกจากโรงภาพยนตร ค าๆ นมล าดบกจกรรมหลายอยางทสอความหมายของมน ไดแก “Exit”

1. เดนไปทประต 2. ยนมอจบลกบด 3. หมนลกบด 4. ดงประต 5. เดนออกจากประต

(2) Data Abstraction (เชงขอมล) คอ รายละเอยดตางๆ ของขอมลทบงบอกถงสงทเกยวของกบระบบ เชน “Door” กลมขอมลทเกยวของค าน คอ

“Door” 1. ชอโรงงานผลต 2. รนของประต 3. ทศทางการเปด (เขา หรอ ออก) 4. ความกวางและความสง

**Classes are data abstraction that contain procedural abstractions 1.2 Refinement

ออกแบบในลกษณะ Top-down

ขยายรายละเอยดเปนล าดบขน (Hierarchy)


1.3 Modularity การแบงระบบหรอซอฟตแวรแยกออกเปนสวนๆ แตละสวน เรยกวา โมดล (Module) ซงจะประกอบกนไดเพอ

ท างานตามความตองการ

easier to build, easier to change, easier to fix

การแบงระบบเปนโมดลจะชวยใหการออกแบบงานในแตละสวนงายขน นอกจากนยงชวยใหการวางแผนพฒนา การแกไขหรอเปลยนแปลง ตลอดจนการทดสอบและซอมบ ารงเปนเรองงาย

**การแกปญหาขนาดใหญ ยอมยากกวาการแกปญหาทถกแบงเปนปญหายอยๆ แลว

เพมเตม 1) Top-down design เหมาะกบงานทมรปแบบหรอมความรอยแลว และสามารถเลอกมาใชไดเลย 2) Bottom-up design เหมาะกบงานทไมเคยมความรเลยจ าเปนตองเจาะทละจดกอน

1.4 Software Architecture

The hierarchical structure of procedural components & the structure of data

Transition between analysis and design

ท าการแบงระบบออกเปนระบบยอยและระบความสมพนธของระบบยอยตางๆ

ผลลพธของกจกรรมน คอ เอกสารทบรรยายตวแบบของระบบและความสมพนธของระบบยอยตางๆ 1.5 Control Hierarchy/Program Structure

จดล าดบของโมดลตางๆ ในโปรแกรมใหอยในลกษณะของการควบคมทเปนล าดบ (Hierarchy of control)

Metrics - Depth จ านวนระดบ (level) ของการควบคม (control) - Width ความกวาง สวนทมระยะกวางมากทสด - Fan-out จ านวนโมดลทถกควบคมโดยตรงโดยโมดลหนงๆ - Fan-in จ านวนโมดลทควบคมโมดลหนงๆ

Visibility & connectivity

fan-out ออกจากตวไป

ตดตอกบ module อน

fan-in หลาย module

เขามาทตว


1.6 Data Structure

อธบายถงความสมพนธทางตรรกะของขอมลในระบบ ออกแบบรายละเอยดโครงสรางขอมลทใชในโมดลตางๆ

มผลกระทบโดยตรงตอโครงสรางของระบบ - การเขาถงขอมล - การประมวลผล - วธการ - ฯลฯ

1.7 Software Procedure

เนนรายละเอยดในการประมวลผลแตละโมดล - ล าดบเหตการณ - จดตดสนใจ - การท างานซ า - โครงสรางขอมล

1.8 Information Hiding การออกแบบโมดลตองท าให Procedure และ Data ไมสามารถเขาถงไดโดยตรงจากภายนอกได คณสมบต

“การซอนสารสนเทศ” คอ การใหนกออกแบบจดเกบรายละเอยดสารสนเทศตางๆ โครงสรางขอมลและตวแปรตางๆ รวมทงรายละเอยดการท างานภายในโมดลไมใหโมดลอนเหน เปนเหมอนการสรางกรอบก าแพงใหกบสารสนเทศภายในโมดล

2. Modular Design

Benefits - ลดความซบซอน - แกไขและเปลยนแปลงไดงาย - Implement ไดงาย

Activation mechanisms

Pattern of control

3. Functional Independence

Benefits - งายในการพฒนา - งานในการบ ารงรกษาและทดสอบ

Measures of Independence

- Cohesion การขนตอกนภายในโมดล (มากๆ ด) → แตละ module ควรท าแคอยางเดยว

และเปนคณสมบตทด module ทมความสมพนธกนมาอยดวยกน

- Coupling การขนตอกนระหวาง Sub system (นอยๆ ด) → module ทมความสมพนธกนแต

แยกกนอยจงท าใหมปญหา เปนคณสมบตทไมด


2: Class Diagram and Sequence Diagram

Class diagram คอ แผนภาพทแสดงเซตของคลาส สวนตอประสาน (อนเตอรเฟส) การท างานรวมกนและ

ความสมพนธของคลาส Class diagram → runtime

Object diagram → design time

1. องคประกอบหลกของแผนภาพคลาส (1) Class

ชอคลาส (Class name)

ลกษณะประจ า (Attributes) - พลบบค (Public) ใชสญลกษณ + - โพรเทกต (Protected) ใชสญลกษณ # - ไพรเวท (Private) ใชสญลกษณ -

การด าเนนการ (Operation)

การเขยน Class diagram สามารถเขยนได 2 แบบ

Class name เปนตวหนา

Person

- TaxIDNo : String - Name : String + Income : double + TaxPaid : Boolean + calcTax() + calcTaxBal()

(2) Relationships - Generalization (รบทอดคณสมบต) A Inheritance B กบ C B กบ C Generalize A

A

B C

Person

Attributes

Attribute name:

Type Operation

Operation name (parameter:

type)


- Implement

- Association

A เปน Associate ของ B

- Aggregation (รวมกลม)

Aggregation

A เปน Aggregate ของ B (Whole) (Part)

Composition

A เปน Composite ของ B

- Aggregation Polygon ม point เปนองคประกอบยอย - Composition ถา Polygon ถกลบ สวนยอยคอ Graphics Bundle จะถกลบไปดวย ถ า Graphics Bundle ถ ก ล บ Polygon อาจจะถกลบหรอไมใหดพวก *, 0…* เปนตน

Polygon 1 รป ตองม Point อยางนอย 3 จด

A B

A B

A B

Polygon

Point

Graphics Bundle color texture

Aggregation and composition

1 1 1

3..*

A

B


- Dependency A depend on B

ถา B เปลยน A ไมเปลยน ถา A เปลยน B ไมเปลยน

** Dependency < Association < Aggregation < Composition

2. การระบความสมพนธของแผนภาพคลาส (1) เพยง 1 แผนกหนงจะมหวหนาเพยง 1 คน (2) 0 หรอ มากกวา พนกงานคนหนงจะมลกกคน หรอไมมกได (3) 1 หรอมากกวา หวหนาหนงคนจะรบผดชอบพนกงานมากกวา 1 คน (4) ชวง พนกงานหนงคนจะมชวงลาพกรอน 2 – 4 วน (5) ระบชวงไมตอเนอง พนกงานหนงคนสามารถเปนสวนหนงของ

คณะกรรมการได 1 ถง 3 หรอ 5 คณะ เพมเตม

ประเภทของ Class - Concrete Class → class ทมความพรอมทจะ initiate เปน object ได

- Abstract Class → class ทไมพรอมทจะ initiate โดยในชอ method จะมค าวา Abstract อย และทชอม <<abstract>> เขยนอยขางบน

Stereotype

A B

แผนก หวหนา 1

พนกงาน ลก 0..*

หวหนา พนกงาน 1..*

พนกงาน พกรอน 2..4

พนกงาน คณะกรรมการ 1..3, 5

B

<<abstract>> ชอคลาส

<<abstract>> Method

Abstract

Concrete

- Persistent Object → object ทไมตาย (มกถกเกบใน

DB)

- Transient Object → Object ทตายแลว


การแก Multiple Inheritance

Multiple Inheritance (ไมนยมใชวธน)

การแกปญหา Multiple Inheritance คอ ตองเลอกตวใดตวหน ง ใ ห เป น Inheritance แ ลวอ กตวหน ง ใ ห เป นการ implement นนคอ class หนงๆ สามารถ inheritance มาไดแค 1 class แตสามารถ implement มาไดจากหลายๆ class

3. Sequence Diagram

การเขยนชอ object Member: LibraryMember → object ชอ member (เทานน) ใน type Library

:BookCopy → object ใด ๆ ใน type BookCopy

ตองสงไปท object ชอ member เทานน

X

op1()

A

op2()

B

X

op1()

A

op2()

B

ชอของ

method(message)

Result ของ method วธการเขยน

condition


Message Types - Synchronous สง message ไป แลวรอใหอกฝายตอบกลบมากอน (ไดรบคา return) จงจะท างานตอ - Asynchronous สง message ไป แลวไมตองรออกฝาย (ไมรอคา return) มนจะท างานอนไดเลย (ปกตมคา return มาทนท เชน yes, no แตไมใชคาทเปน result จากการท าฟงกชนนน) - Simple - Create - Destroy

- เสนทบคอสง

message

- เสนประคอ return

คา


3: Streamlined Object Model (Patterns, Rules and Implementation)

The Pattern Players People Actor Role Places Place & OuterPlace Things Item & Specific Item Assembly & Part Container & Content Group & Member Events Transaction Composite Transaction & Line Item Follow-up Transaction

1. Actor - Role An actor can know about multiple roles, but can take on only one of each kind. (1) Actor – Role Generalization การออกแบบทง 2 คอ แบบ Actor – Role และแบบ Generalization จะแตกตางกนเมอมการเพม class ใหม แบบ Role จะดกวาเพราะไมกระทบกบ Class Person แตถาแบบ Generalization จะกระทบ Class Person

Customer Employee

Person

Broker


ตางจากรปท (1) ตรงท Person ในภาพน จะตองมาเปน TeamMember กอน ซง TeamMember สามารถก าหนด Role พนฐานของสมาชกบางคนเปน TeamChair หรอ TeamAdministrator กได หรออาจจะเปน TeamMember ทว ๆ ไปโดยไมไดเปน TeamChair หรอ TeamAdminitrator กได โดย TeamMember ทวไป จะใช Role ทก าหนดใน class TeamMember ซงรปท (1) จะก าหนดท class Customer, Employee และ Broker เลย

2. Outer Place - Place The outer place - place pattern models locations where interactions between people and things

happen. This pattern models a location for interactions with two types of objects - one describing the event location (place), and an optional second object (outer place) when the location is hierarchical.

An outer place knows at least one place, and serves as the container of its places

ความสมพนธจะเปน 1 กบ

1..* เสมอ

Transaction จะเกดท Place หากม การ Loading ก จะท าท LoadingArea หากมการ Shipping กจะท าท ShippingArea

Transaction จะเกดทตวลางสดคอ LoadingBin เพราะการ track จากลางขนบนสามารถท าได แตจะ track จากบนลงลางจะท าไดยาก เนองจากความสมพนธเปนแบบ 1..*

3. Item – Specific Item

The item describes the information that is common across all variations.

The specific item describes the information that makes each variation distinctive. Also, the specific

item participates in events. เชน ของหมด (Out of stock)


ชอหนง หนงแผนท 1 หนงแผนท 2

เชน กรณ Notebook

ถาเปน Notebook ของเรา Notebook อาจจะเปน Item เพราะเราจะม

Notebook มยหอ รน โมเดล อนเดยวจงไมตองเกบ specific item

ถาเปนรานขายคอมพวเตอร Notebook จะเปน specific item เพราะ

Notebook แบบเดยวกนอาจจะมหลายตว

กวนมนโฮ พากษไทย แผนท พากษเกาหล 4. Assembly - Part

The assembly - part pattern is one of the patterns for modeling things with complex structures. It is used to model a thing that is constructed from other things. This pattern differs from the other complex structures, container and group, because it cannot exist without at least one part. Part คอ Component เปนสวนหนงของ Workstation


** Assembly – Part ตางจาก Place – Outer place ตรงท place ตองอยใน 1

Outer place แต part อาจจะอยลอย ๆ กไดไมจ าเปนตองอยใน Assembly เสมอ

ไป

5. Container - Content Use the container - content pattern when a thing is a receptacle or storage place for other things. 6. Group - Member

It is frequently used to model collections and classifications of things, and it can also be used for collections of people and places.

Category อาจจะไปอยใน category อน

7. Transaction - Role

The transaction - role pattern models an entity interacting with things at places.

The role pattern player is used instead of actor because the role describes an entity's participation within a context, and an interaction always occurs within a context.


คมตรงนวาจะ assign ใครใหตดเกรด

คอใช Transaction role

เรมแรกนาย A เปนอาจารยและสามารถตดเกรดได แตแลวนาย A กลาออก จากนนมนาย B มาเปนอาจารยและตองตดเกรดแทน หากใชการออกแบบตามแบบท 2 หากเกดกรณท admin ลมลบการใชงานของนาย A ออกจากระบบ ท าใหนาย A ยงสามารถท าการตดเกรดได แตหากใชการออกแบบตามแบบท 1 คอท าการ assign ตรงผสอนกจะสามารถปองกนการเกดปญหานได 8. Transaction - Place

A transaction knows about one place. When a time-interval transaction occurs in more than one place, then it is best to model that event as a composite transaction containing multiple single transactions, each at a different location. In these cases, the single transactions are acting like line items within the composite transaction

คอ Transaction เกดท Place ใน Outer Place ดงนน Transaction จง

เกดไดท Place เดยว

ผสอน ตดเกรด

แบบท 1

A

B

ตดเกรด

แบบท 2

A

B


9. Transaction - Specific Item

Models the involvement of a thing in an interaction. Here the thing is involved as the subject of the interaction, not the doer of the interaction, and only one thing is involved. The specific item pattern player is used instead of the item pattern player because an event requires a thing with distinguishing details, whereas an item is a common description for a set of things.

เชน ซอ Notebook แลว Notebook เครองไหน

Transaction specific item

**การเขยน Class diagram → ให transaction เปน center ไมใช person (เนองจากทวไปคนมกเขยน Actor เปน center แตจรงๆ แลวควรเขยน transaction เปน center)

ใหอาหารส าหรบววแตละ

ตว


4: Modeling with UML

1. Package

A package is a grouping of model elements

การตงชอ namespace ของ package จะตงโดยใช revert domain name เชน ibm.com → com.ibm, apachae.org → org.apachae

Core Concepts

Construct Description Syntax Package A grouping of model elements.

Import A dependency indicating that the public contents of

the target package are added to the namespace of the source package.

<<import>>

Access A dependency indicating that the public contents of <<access>>


the target package are available in the namespace of the source package.

Import

The associations are owned by package X

Import - Alias

การท า Alias คอเปลยนชอ

An imported element can be given a local alias and a local visibility


**Alias ท า เพอเปลยน

ช อ ใ ห ส า ม า ร ถ

เรยกใชได สะดวกใน

package ใ ห ม

เพราะหาก ใชชอเดม

เ ม อ เ ร ย ก ใ ช

จ ะ ต อ ง เรยกเตมๆ

package ค อ อ า ง

ดวย

Access

The associations are owned by package X

Import vs. Access


F ถก Package Y import มา จากนน Package X import F มาจาก Y ซง

Package X จะเหนวา F เปนของ Package Y เพราะจะเหนเฉพาะตวทถก import

โดยตรง

Diagram Tour


- Packages are shown in static diagrams - Two equivalent ways to show containment

จะเหนความสมพนธของ class ใน Package จะไม เหนความสมพ นธของ

class ใน Package

แต มองได งายถ าม package ซ อน

package

Modeling Tip - Package - Gather model elements with strong cohesion in one package - Keep model elements with low coupling in different packages - Minimize relationships, especially associations, between model elements in different packages

Minimize relations เพ ราะห ากม relation ก น เยอ ะๆ ห ากต วหน ง

เปลยนแปลงอก package จะไดรบผลกระทบดวย ดงนนย ง relation เยอะ

ผลกระทบกจะเยอะดวย

- Namespace implication: an element imported into a package does not “know” how it is used in the imported package 2. Subsystem

Complete system ท า design มาเพอท าให complete ในตวมนเอง ไมได

design ใหสามารถ re-use ไดเหมอน package


Core Concepts

Construct Description Syntax Subsystem A grouping of model elements that represents a

behavioral unit in a physical system.

Subsystem Aspects A subsystem has two aspects:

- An external view, showing the services provided by the subsystem - An internal view, showing the realization of the subsystem

→ Mapping between the two aspects **A subsystem has a specification and a realization to represent the two views

Subsystem Specification Subsystem Realization - Defines the external view of the subsystem** - Describes the services offered by the subsystem - Describes the externally experienced behavior of the subsystem - Does not reveal the internal structure of the subsystem - Describes the interface of the subsystem

- Defines subsystem the actual contents of the subsystem** - Consists of classes and their relationships, or a contained hierarchy of subsystems with classes as leaves

เทคนคทใช - Use Case - State Machine - Logical Class - Operation และการใชเทคนคขางตนรวมกน

Mapping specification และ realization - realization relationships - collaborations ม 2 Diagram ทใช คอ

→ Sequence Diagram → Collaboration Diagram


ตวอยาง Subsystem Specification Use Case Approach

- For subsystem services used in certain sequences - When the specification is to be understood by non-technical people

State Machine Approach

- For subsystems with state dependent behavior - Focuses on the states of the subsystem and the transitions between them

Logical Class Approach

- When usage of the subsystem is perceived as manipulation of objects - When the requirements are guided by a particular standard

Operation Approach

- For subsystems providing simple, “atomic” services - When the operations are invoked independently

Mixing Techniques


ตวอยาง Subsystem Realization - Realize Relationship

→ Realization is particularly useful in simple mappings โครงสราง

ตวอยาง

- Collaboration → A collaboration defines the roles to be played when a task is performed

→The roles are played by interacting instances

→ Collaborations are useful in more complex situations Collaboration – Notation


ตวอยาง

Subsystem Interaction

Communicating with Subsystems - Open subsystem - public elements are accessed directly - Closed subsystem - access via the subsystem itself


L1

L2

L3

L1

L2

L3

L1

L2

L3

M

P1 P2 P3

ตวจดการการเชอมตอระหวาง

P1 P2 P3 L1

P1 P2 P3 L2

P1 P2 P3 L3

5: Software Architecture

- Coupling คอ ความสมพนธกบ package อน → การพ งพากนระหวาง 2

boundary (class, package หรอ subsystem แลวแตเรานยาม)

- Cohesion คอ ความสมพนธกนของแตละ class ใน package

1. Partitions and Layers

Partitions vertically divide a system into several independent (or weakly-coupled) subsystems that

provide services on the same level of abstraction → ตดตามแนวตง

A layer is a subsystem that provides subsystem services to a higher layers (level of abstraction) →

ตดตามแนวนอน ขอดของการแบง layer คอ สามารถยายงานตางๆ ไดงาย

(Portable) - A layer can only depend on lower layers - A layer has no knowledge of

higher layers


2. Closed Architecture (Opaque Layering) and Open Architecture (Transparent Layering)

Closed Architecture เหนเฉพาะชนทตดกนมประสทธภาพสงสด

- Design goal: High maintainability, flexibility

→ Layer ใช Layer ทตดกนเทานน และหาม Layer ลางใชชนบน (ลกศรหามชขน)

Open Architecture ไ ม แ น ะ น า ใ ห ใ ช

(coupling นอย cohesion มาก)

- Design goal: Runtime efficiency

→ ชนนอกสามารถเรยกใชชนในทไมไดอยตดกนได ท าใหการท างานเรวขนแต flexibility กบ maintainability ต า

* Cohesion มประโยชนในดาน Maintenance และ Re-Use

→ การ Maintenance ม 4 แบบ คอ

1. Corrective (แก Error)

2. Adaptive

3. Enhancement

4. Preventive

ตวอยาง Coupling


จากภาพท High Coupling แกโดยการยาย M3 ออกจาก Subsystem B

จะไดเหลอการเชอม 2 Subsystem ใหเหลอเพยงเสนเดยว เพราะใน Subsystem

B สวนของ M3 และ M4 กไมมความสมพนธตอกนอยแลว

2. Software Architecture Design

Client/Server - One or many servers provide services to instances of subsystems, called clients. - Client calls on the server, which performs some service and returns the result

→ 1 ตวเปนไดอยางเดยว จะเปนทง client และ server ไมได

- Design goals (1) Service Portability

Server can be installed on a variety of machines and operating systems and functions in a variety of networking environments

(2) Transparency, Location-Transparency The server might itself be distributed (why?), but should provide a single "logical" service to

the user (3) Performance

Client should be customized for interactive display-intensive tasks Server should provide CPU-intensive operations

(4) Scalability Server should have spare capacity to handle larger number of clients

(5) Flexibility


The system should be usable for a variety of user interfaces and end devices (eg. WAP Handy, wearable computer, desktop)

(6) Reliability System should survive node or communication link problems

- ขอเสย Client → ตองจ า server วามอะไร ตวไหนท าอะไร และมโอกาสเกด deadlock

Server → ตองท างานตลอด ถาเครอง server เสยกจะไมสามารถใหบรการได

Peer-to-Peer - เปนทง Client และ Sever ไดในเวลาเดยวกน - Client เกด deadlocks ไดยาก

Model/View/Controller (MVC) - Subsystems are classified into 3 different types

Model subsystem: Responsible for application domain knowledge View subsystem: Responsible for displaying application domain objects to the user Controller subsystem: Responsible for sequence of interactions with the user and notifying

views of changes in the model. - MVC is a special case of repository architecture: Model subsystem implements the central data structure, the Controller

subsystem explicitly dictate the control flow

BCE → Boundary control entity

Repository Architectural Style (Blackboard Architecture) - Subsystems access and modify data from a single data structure - Subsystems are loosely coupled (interact only through the repository) - Control flow is dictated by central repository (triggers) or by the subsystems (locks, synchronization

primitives)

V

C

M

C

B E


- ท างานผาน Repository

- ถาม repository 1 เครอง และม Subsystem 50 เครอง จะมเสนเชอม n-1

= 50-1 = 49

Pipe and Filter - Subsystems process data received from a set of inputs and send results to other subsystems via a set of outputs - The subsystems are called “Filters” - The associations between the subsystems are called “Pipes”

- data จะ flow ผาน pipe ไปยง filter ตวถดไป

- ทกตวจะเปน Filter แลวเสนทเชอมจะเปน Pipe ซงตางจาก Peer-to-

Peer ตรงททก data ใน Pipe จะม format เดยวกนหมด

- ขอด สามารถถอด Filter ออกแลวเอาตวใหมแทนไปไดทนทโยทไม

กระทบกบตวอน

- ขอเสย ม overhead เพราะตองประมวลผลกอนสง

ม post-

processing

ม pre-processing


6: Design Pattern

1. The Strategy Pattern

ใชเมอมการแกปญหาบอย ๆ (มการเปลยนแปลงบอย)

แยกสวนทมการเปลยนแปลงบอยออกมา แลวคอยให class มาเรยกใชแทน

การเลอกพฤตกรรมจะสามารถเลอกไดเพยงครงละ 1 พฤตกรรมเทานน หากเลอก 2 พฤตกรรมจะเกด Duplicate code

บทบาท เชน employee คนหนงมหลาย role

*change behavior at runtime

Object Diagram - Object Diagram ของ D1 ทเปด MallardDuck บนดวย F1 เปน FlyWithWings และรอง Q1 เปน Quark


Sequence Diagram

- Sequence Diagram ของการก าเนด D1

- Sequence Diagram ของ D1 ทเกดมาแลวถกสงใหบน

เรมตรงเสน เพราะไมไดมอยตงแตแรกเพง

ถกสรางใหเกด

เกดมาแลวเลยม timeline

ตงแตแรก


(2) Observer Pattern แกปญหา Coupling

The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.

The subject and observers define the one-to-many relationship. The observers are dependent on the

subject such that when the subject’s state changes, the observers get notified. Depending on the style of notification, the observer may also be updated with new values.


Designing the Weather Station


(3) Decorator Pattern

สามารถเพมไดเรอยๆ เชน กาแฟจะเพมสวนผสมอน อาท เพมชอกโกแลตชบ เพมวปครม เปนตน

เชควาเปนตวในสดหรอยง เมอถงตวในสดมนจะรเองวาสดทางแลว กจะเรมท าจากตวในสดและ return คามา

Our goal is to allow classes to be easily extended to incorporate new behavior without modifying existing code.


Decorating our Beverages


การท างาน

Sequence Diagram - Sequence Diagram ของการก าเนดกาแฟ Espresso


- Sequence Diagram ของการคดเงน

The Open-Closed Principle

Classes should be open for extension, but closed for modification

(4) Factory Pattern


(5) Singleton

ใชเมอตองการควบคมใหมแค 1 instance (ใช control อะไรบางอยาง เชน Login)

ขอด - โหลดเรว - ใชในการควบคมไดงาย

ขอเสย - ตอนใชงานจะตองเสยเวลาในการโหลด

**The Singleton Pattern ensures a class has only one instance, and provides a global point of access to it.


(6) Command Pattern

คนท ากบคนรบไมรจกกน

**The Command Pattern encapsulates a request as an object, thereby letting you parameterize other objects with different requests, queue or log requests, and support undoable operations.

Sequence Diagram - Sequence Diagram ของการก าเนดรโมท

จ านวน Command Object จะเทากบ

สงทมนท าได เชนถาใหเปดไดอยาง

เดยว กจะม 1 object แตถาให

สามารถเปดและปดไดกตองม 2

object

1: software design fundamentalssoftware design and development_pon’2013 | 3 1.6 data structure...

Documents