Các bạn có thể xem loạt clip về SOLID tại đây: https://www.youtube.com/playlist?list=PLRLJQuuRRcFlRei0t0wbbCdzU8ujTD3jE
Giờ ta đã có các business entity quan trọng nhất, cũng như định nghĩa ISolver, một “bản hướng dẫn” cách giải quyết vấn đề. Đúng vậy, ISolver là một interface, tự nó không thể giải được bài toán, nhưng nó đóng vai là bản cam kết, là một “contract” cho việc giải bài toán PTB1. Và đó cũng là nhiệm vụ của bất kỳ interface nào. Nguyên tắc đơn giản là: tôi không biết anh là ai, nhưng nếu anh implement ISolver, vậy chắc chắn anh có thể giải được bài toán này, anh có thể dùng đầu óc tính toán thông qua các phép cộng trừ nhân chia để tìm ra kết quả, hoặc như trong trường hợp của DistributedSolver (xem phần 2), anh phân phối lại các yêu cầu cho các máy tính khác và tổng hợp lại.
Vậy ta sẽ cần ít nhất một lớp hiện thực hóa ISolver, ta đặt tên nó là LocalCpuSolver (đặt tên hoành tráng một chút mới bán được nhiều tiền):
public interface ISolver {
Result Solve(Constants constants);
}
public class LocalCpuSolver implements ISolver {
Result Solve(Constants constants) {
return new Result() {
...
};
}
}Tới đây, ta đã có một ISolver cụ thể (chính là LocalCpuSolver), hoàn toàn độc lập, bạn có thể viết các unit test và gắn vào để chạy, việc LocalCpuSolver chỉ phụ thuộc duy nhất vào ISolver giúp chúng ta dễ dàng kiểm thử, dễ dàng thay thế các instance của nó với instance của một class khác. Một thiết kế có càng ít mối phụ thuộc càng dễ bảo trì, chỉnh sửa, thay đổi… vậy nên, khi thiết kế, hãy cố gắng làm mọi thứ thật đơn giản.
Tương tự, ta sẽ xây dựng hai lớp ConsoleResultWriter và ConsoleConstantsReader, cho các interface IResultWriter và ConstantsReader (xem lại bài 2).
Continue reading “Open Close Principle – phần cuối”
).
. Bạn sẽ học mãi, học mãi, tìm giải pháp, giải quyết vấn đề, một hôm nào đó lại thấy một vấn đề mới trong giải pháp tưởng chừng hoàn hảo đó, rồi lại học, lại suy nghĩ…
Mục đích của vẽ diagram, kể cả các UML diagram là để giúp thiết kế/lập tài liệu dễ dàng hơn, không phải là một phương pháp thiết kế.
). 
Khi nào tôi có thể bắt đầu học về phân tích thiết kế: Để bắt đầu học, bạn cần tương đối thành thạo về lập trình, đặc biệt lập trình hướng đối tượng (OOP). Hãy nhớ OOP là một cách tư duy về tổ chức chương trình, chứ không chỉ là một phương thức lập trình. Bạn thậm chí có thể bắt đầu học về phân tích thiết kế từ năm 1, năm 2 đại học, tùy vào khả năng của bạn lúc đó đến đâu.
.
Đào Hải Nam 