Nếu các bạn đã đọc đến đây thì tôi xin gửi lời cảm ơn trước tiên. Những gì tôi viết ra, có những thứ nằm trong kế hoạch, nhưng cũng có những thứ ngẫu hứng. Nhiều chỗ còn khá lộn xộn và cần bạn phải tự sắp xếp để mạch lạc hơn. Có lẽ tôi sẽ cố gắng biên soạn lại một lần, bổ sung những góp ý của mọi người để nó hoàn thiện…
Leave a Commentrefacore Posts
Đối với nguyên tắc cuối này, nếu các bạn đều đã hiểu các nguyên tắc trước đó thì cũng không còn gì nhiều để nói về nó. Trong Liskov Substitution đã có một phần của Dependency Inversion. Trong Open/Close cũng thế. Có cả trong Interface Segregation. Tất cả những nguyên tắc kể trên đều có mối liên kết là Dependency Inversion. Đối với Liskov Substitution, bạn tạo sự phụ thuộc qua các lớp cha, và…
Leave a CommentBài trước tôi đã đưa ra bàn luận về Interfact Segregration và cũng có nói bài này sẽ bàn luận việc kiến trúc phần mềm hiện tại mài mòn kĩ năng OOP của chúng ta ra sao. Thực ra điều này cũng không có gì xấu. Cái gì có ích thì tồn tại và các kiến trúc phần mềm hiện đại tỏ ra hiệu quả hơn việc đi sâu vào thiết kế OOP. Điều này…
Leave a CommentNguyên lý này có một phát biểu rõ ràng nhưng lại mù mờ trong cách hiểu và cách áp dụng. Bạn có đang thực sự áp dụng nguyên lý này trong công việc? Có một vài lý do. Trước tiên tôi muốn chúng ta làm rõ về cách tiếp cận. Một class không thừa kế interface, nhưng thực thi interface Mặc dù interface nằm trong danh sách thừa kế của một class, nhưng về bản…
Leave a CommentLiskov Substutition là một nguyên tắc khá trừu tượng. Có một vài ví dụ kinh điển như con vịt đồ chơi trong họ nhà vịt, hay hình vuông có thừa kế từ hình tam giác hay không. Cùng xét một một best practice điển hình, phổ biến mà có thể liên tưởng tới Liskov Substitution: Khởi tạo giá trị mặc định cho thuộc tính Việc này thường là để giải quyết Null Exception. Có nghĩa…
Leave a CommentPhần này tôi muốn đưa tới các bạn một ví dụ thực tế về Open/Close, một tình huống cân đo đong đếm giữa Extend hay là Modify. Cùng xem biểu đồ lớp dưới đây mô tả giải pháp cho chức năng chuyển đổi một model thành một trang markup (html hay xml …).Đây là một phần code trong dự án của tôi, bao gồm một phần code cũ và một phần code mới được refactor.…
Leave a CommentTôi có được nghe hai lần câu chuyện ở một công ty lớn ở Việt Nam, một Solution Architect đã từ chối một pull request của đồng nghiệp với lý do các thay đổi không tuân theo nguyên tắc Đóng/Mở. Tôi nghĩ rằng đã có một yêu cầu từ khách hàng và lập trình viên đã sửa đổi một lớp sẵn có để thực hiện yêu cầu ấy. SA đã từ chối vì theo SA,…
Leave a CommentTrong bài trước, tôi đã đề cập đến nhầm lẫn cơ bản dẫn đến hiểu sai về đơn nhiệm. Trong bài này, tôi muốn đưa ra một cách tiếp cận để giúp chúng ta có thể đạt được tính đơn nhiệm trong những dòng code của mình. Trước tiên, hãy chú ý đến các điểm sau: Đơn nhiệm không chỉ áp dụng cho class Trong định nghĩa về đơn nhiệm chỉ nói về class, nhưng…
Leave a CommentTrong bài trước tôi đã trình bày một vài ví dụ lấy từ mã nguồn của Microsoft về việc vi phạm Đơn nhiệm (và kể cả một số lỗi coding convention thông thường). Một trong những lý do là thiết kế cũng như kiến trúc mà chúng ta tường dùng không đảm bảo được sự tuân thủ. Điều này thực ra cũng không có gì to tát. Các nguyên tắc vốn không thể tuân thủ…
Leave a CommentRepo: https://github.com/refacore/ioc-event Xử lý sự kiện là kĩ thuật được sử dụng phổ biến. Các nền tảng cung cấp các cách khác nhau để xử lý sự kiện. Chúng ta có thể lựa chọn các chức năng được cung cấp sẵn hoặc tự xây dựng một bộ xử lý của riêng mình. Dưới đây là 3 phương án với C#. event của C Khai báo event và event theo cách mà C# cung cấp. Đây…
Leave a Comment