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 Topics Software Design Patterns – What & Why Example Pattern: Publisher-Subscriber (. 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 ., 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 Topics Software Design Patterns – What & Why Example Pattern: Publisher-Subscriber (. 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 ., 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 .

Không thể tạo bản xem trước, hãy bấm tải xuống
TÀI LIỆU MỚI ĐĂNG
Đã phát hiện trình chặn quảng cáo AdBlock
Trang web này phụ thuộc vào doanh thu từ số lần hiển thị quảng cáo để tồn tại. Vui lòng tắt trình chặn quảng cáo của bạn hoặc tạm dừng tính năng chặn quảng cáo cho trang web này.