Please enable JavaScript.
Coggle requires JavaScript to display documents.
Agile Principles, Patterns, and Practices in C# Chapter 7, 8 & 9 -…
Agile Principles, Patterns, and Practices in C# Chapter 7, 8 & 9
Chapter 7. What Is Agile Design?
Design smells
Design smells là sự vi phạm các nguyên tắc thiết kế cơ bản và tác động tiêu cực đến chất lượng thiết kế
Rigidity là xu hướng phần mềm khó thay đổi, ngay cả theo những cách đơn giản
Fragility: tính dễ vỡ xu hướng của một chương trình bị phá vỡ ở nhiều nơi khi một thay đổi duy nhất được thực hiện
Immobility: Một thiết kế là bất di bất dịch khi nó chứa các bộ phận có thể hữu ích trong các hệ thống khác, nhưng nỗ lực và rủi ro liên quan đến việc tách các bộ phận đó khỏi hệ thống ban đầu là quá lớn.
Viscosity: là một trong đó thiết kế của phần mềm khó được bảo toàn.
Needless complexity: Là không cần thiết khi nó chứa các yếu tố hiện không hữu ích
Needless repetition: Là những thao tác chỉnh sửa văn bản hữu ích, nhưng chúng có thể là những thao tác chỉnh sửa mã tai hại các hoạt động
Opacity: là sự khó hiểu của một mô-đun
Agile design là một quá trình, không phải một sự kiện. Đó là ứng dụng liên tục của các nguyên tắc, mẫu và thực hành để cải thiện cấu trúc và khả năng đọc của phần mềm. Nó là cống hiến để giữ cho thiết kế của hệ thống luôn đơn giản, sạch sẽ và biểu cảm nhất có thể.
Chapter 8. The Single Responsibility Principle
Một class chỉ nên giữ một trách nhiệm duy nhất
(Chỉ có thể thay đổi class vì một lý do duy nhất)
Một class có quá nhiều chức năng cũng sẽ trở nên cồng kềnh và phức tạp.
Nếu một class có quá nhiều chức năng, quá cồng kềnh, việc thay đổi code sẽ rất khó khăn, mất nhiều thời gian, còn dễ gây ảnh hưởng tới các module đang hoạt động khác.
Trong bối cảnh của SRP, chúng ta xác định trách nhiệm là lý do để thay đổi. Nếu có thể nghĩ về nhiều hơn một động cơ để thay đổi một lớp, thì lớp đó có nhiều hơn một trách nhiệm.
Chapter 9. The Open/Closed Principle
Có thể thoải mái mở rộng 1 module, nhưng hạn chế sửa đổi bên trong module đó (open for extension but closed for modification).
Một module cần đáp ứng 2 điều kiện
Dễ mở rộng: Có thể dễ dàng nâng cấp, mở rộng, thêm tính năng mới cho một module khi có yêu cầu.
Khó sửa đổi: Hạn chế hoặc cấm việc sửa đổi source code của module sẵn có
Nguyên tắc Mở / Đóng là trọng tâm của thiết kế hướng đối tượng.
Lợi ích của việc áp dụng nguyên tắc này là: tính linh hoạt, khả năng tái sử dụng và khả năng bảo trì.