Đang chuẩn bị liên kết để tải về tài liệu:
Lecture Software engineering: Lecture 17 - Ivan Marsic

Lecture 17: Design patterns (publisher-subscriber). This chapter presents the following content: What developers do with software, the power of patterns, software design patterns, object responsibilities (toward other objects),. | Ivan Marsic Rutgers University LECTURE 17: Design Patterns Publisher-Subscriber http://en.wikipedia.org/wiki/Problem_Frames_Approach Topics Software Design Patterns – What & Why Example Pattern: Publisher-Subscriber (a.k.a. Observer) What Developers Do With Software (besides development) Understand (existing software) Maintain (fix bugs) Upgrade (add new features) The Power of Patterns CN NIB MAP PLE The Power of Patterns The Power of Patterns CNN IBM APPLE The Power of Patterns The Power of Patterns CN NIB MAP PLE CNN IBM APPLE Software Design Patterns Design Patterns help anticipate software change Change is needed to keep up with reality Change may be triggered by changing business environment or by deciding to refactor classes that are deemed potentially problematic e.g., using quality-screening metrics (see Chapter 4) Change may have bad consequences when there are unrelated reasons to change a software module/class Unrelated . | Ivan Marsic Rutgers University LECTURE 17: Design Patterns Publisher-Subscriber http://en.wikipedia.org/wiki/Problem_Frames_Approach Topics Software Design Patterns – What & Why Example Pattern: Publisher-Subscriber (a.k.a. Observer) What Developers Do With Software (besides development) Understand (existing software) Maintain (fix bugs) Upgrade (add new features) The Power of Patterns CN NIB MAP PLE The Power of Patterns The Power of Patterns CNN IBM APPLE The Power of Patterns The Power of Patterns CN NIB MAP PLE CNN IBM APPLE Software Design Patterns Design Patterns help anticipate software change Change is needed to keep up with reality Change may be triggered by changing business environment or by deciding to refactor classes that are deemed potentially problematic e.g., using quality-screening metrics (see Chapter 4) Change may have bad consequences when there are unrelated reasons to change a software module/class Unrelated reasons are usually because of unrelated responsibilities Change in code implementing one responsibility can unintentionally lead to faults in code for another responsibility Another target is complex conditional logic (If-Then-Else statements, etc.) What May Change & How What changes in real world are business rules customer requests changes in software Changes in the small—changes in object responsibilities towards other objects Number of responsibilities Data type, or method signature Business rules Conditions for provision/fulfillment of responsibilities Sometimes change is regular (follows simple rules), such as new object state defined, or another object needs to be notified about something Object Responsibilities (toward other objects) Knowing something (memorization of data or object attributes) Doing something on its own (computation programmed in a “method”) Business rules for implementing business policies and procedures Calling methods on dependent objects .