Phần lớn những code áp dụng đều là code C++ mong các bạn có một kiến thức khá về C++ bạn có thể tham khảo thêm tại đây
Cuốn sách tham khảo chính cho bài viết là cuốn "Design Pattern - Elements of Reusable Object - oriented Software" các bạn có thể down tại đây
Thuật ngữ
Trong này có một vài thuật ngữ hay sử dụng. Tôi cũng chỉ kế thừa lại từ các tiền bối đi trước, ghi chú vào đây cho những bạn chưa biết tiện theo dõi.
Client : những thành phần khác (có thể trương trình khác, đoạn code khác...) chỗ mà sẽ sử dụng đến các dịch vụ
Server: phần (code) chụi trách nhiệm trưng ra các dịch vụ và sử lý các yêu câu và trả về
I. Ngồn gốc và lịch sử hình thành
i.1. Nguồn gốc
Xuất phát điểm của tư tưởng thiết kế mẫu chính là ý tưởng của một kiến trúc sư nổi tiếng tên ông ta thì tôi đã quên mất rồi. Với ý tưởng tập hợp những cách thức, giải pháp để giải quyết các vấn đề hay gặp trong kiến trúc ông cho ra đời một cuốn sách nói về ngôn ngữ mẫu của kiến trúc. Trong quyển sách đó với mỗi một mẫu sẽ giải quyết một vấn đề cụ thể trong một ngữ cảnh hoàn toàn cụ thể. Việc áp dụng mẫu nào trong hoàn cảnh nào phục thuộc vào những điều kiện đó. Sau một quá trình khái quát hoá (dân coder gọi là sự trùi tượng hoá) thì nó chở thành những mẫu kinh điển để áp dụng cho một số nhiều những vấn đề hay gặp mang tính tổng quát. Chúng ta biết ơn các vị tiền bối đi trước nhờ trí tuệ của họ.
i.2. Lịch sử hình thành
Theo những thông tin mà tôi được biết thì cuốn sách đầu tiên về Design Pattern là của bốn tác giả Erich Gamma, Richard Helm, Ralph Johnson và John Vlisside tựa đề Design Pattern - Elements of Reusable Object - oriented Software tạm dịch là Thiết kế mẫu : Thực thể phần mền hướng đối tượng tái sử dụng. Trong này các tác giả gọi các mẫu của mình là GOF - Gang of four công cụ của 4 người. Trong đó bao gồm 23 mẫu nói về các vấn đề trong kỹ thuật phần mền theo các chủ đề mẫu kiến tạo nói về các vấn đề khởi tạo đối tượng, mẫu cấu trúc bàn về các cấu trúc, tổ chức các thành phần và mẫu hành xử nói về các mô hình giao tiếp, tương tác giữa các thành phần trong một hệ thống. Một điều rất thú vị trong cuốn sách của các vị này là việc họ không chú trọng vào bất kỳ một mẫu nào mà điều họ nhấn mạnh chính là sự tương tác giữa các mẫu với nhau và cách thức chúng cùng nhau làm việc. Hi vọng với chút kiến thức hiểu biết của mình tôi có thể trình bày được vấn đề này.
II. Những nguyên lý trong thiết kế hướng đối tượng
Bàn về việc thiết kế hướng đối tượng thì rất mênh mông. Trong giới hạn của chủ đề chỉ giới thiệu những nguyên lý cơ bản của việc thiết kế hướng đối tượng. Để tìm hiểu về chủ đề này hi vọng sẽ có đủ tài liệu cần thiết và kinh nghiệm để chia sẻ cùng các bạn trong một tương lai không xa. Dưới đây xin trình bày những nguyên lý cơ bản giúp các bạn hiểu được tư tưởng áp dụng của OOD vào việc phân tích các mẫu trong Design pattern
ii.1. Nguyên lý đóng và mở ( open-close )
Đây là nguyên lý cơ bản nhất của viêc thiết kế hướng đối tượng. Nó hình thành dựa trên tính biến động không thể đoán trước được trong vòng đời phát triển của phần mền - điều này đã được Jacobson nói về việc thiết kế phần mền. Sau được Meyer cụ thể hoá và chở thành nguyên lý - nguyên lý open-close.
Nội dung:
Các thực thể của phần mền (class, module, function..) phải mở với việc mở rộng và đóng với việc sửa đổi.
Nội dung của nguyên lý chỉ ra rằng để đáp ứng được với những biến đổi không dự đoán trong tương lai thì ứng dụng nên được thiết kế sao cho hạn chế việc sửa lại code nhưng lại dễ dàng cho việc thêm mới mở rộng các code khác vào. Tức là nếu có bất kỳ những thay đổi gì trong quá trình phát triển thì nên hạn chế việc sửa code đã có mà thay vào đó là thêm vào những code mới để đáp ứng yêu cầu.
ii.2. Nguyên lý về sự kế thừa và thay thế ( liskov - subsitution )
Nguyên lý bàn về một trong những tính chất quan trọng nhất của OO đó là tính kế thừa - inheritance. Để giảm và tránh tình trạng kế thừa vô tội vạ dẫn đến những thiết kế tồi và áp dụng chiệt để tư tưởng đóng và mở nguyên lý này là kim chỉ nam cho việc bạn quyết định mở rộng ứng dụng như thế nào.
Nội dung:
Một lớp chỉ kế thừa từ lớp cha khi thay thế các tham chiếu của lớp cha bằng lớp con mà không làm ảnh hưởng đến trương trình
Việc thay thế hay kế thừa phải bảo đảm rằng những hanh vi giao tiếp của lớp con kế thừa từ cha hoạt động đúng nghĩa. Khi nào một thực thể hành động giông như cha của nó thì đối sử với thực thể đó giống đổi sử với cha nó. Trong ngôn ngữ Ruby có khái niệm là dog mà kêu như duck thì cứ coi như dog là duck (duck typing). Đó là khi bạn nên kế thừa và thay thế.
ii.3. Nguyên lý sự nghịch đảo phụ thuộc ( dependency - inversion )
Đây là nguyên lý được xây dưng trên việc áp dụng chiệt để nguyên lý đóng - mở và nguyên lý kế thừa - thay thế ở mức độ khái quát hoá cao hơn. Nguyên lý gồm 2 mệnh để được phát biểu như sau.
Nội dung:
- Module ở mức độ cao không phụ thuộc những module ở mức độ thấp, Cả hai nên phụ thuộc vào mức độ chùi tượng
- Mức độ chùi tượng không phụ thuộc vào mức độ chi tiết, mà sự chi tiết nên phụ thuộc vào mức độ chùi tượng
Nguyên lý nhấn mạnh đến tính trùi tượng hoá vấn đề từ đó đi đến việc quyết định tạo nên các lớp cơ sở trùi tượng, các giao diện mà lớp chức năng cam kết thực thi.
ii.4. Nguyên lý phân tách giao diện ( interface - segregation )
Hẳn nhiên khi client sử dụng một dịch vụ nào đó được cung cấp bởi server thì client sẽ gọi các phương thức này thông qua giao diện (đây là một thiết kế tốt).
Nội dung:
Client chỉ nên biết đến và sử dụng những gì mà chúng cần
Điều này có nghĩa bạn nên tác các nhóm dịch vụ ra thành những giao diện. khi đó client sử dụng dịch vụ nào sẽ thực hiện gọi chức năng đó, chánh việc dư thừa những chức năng chẳng bao giờ được sử dụng đến bởi client này. Điều này rất có ý nghĩa rất lớn về tính toàn vẹn logic cũng như vật lý của thiết kế hương đối tượng.
ii.5. Nguyên lý sự đơn trách ( single - reponsibility )
Trong những trường hợp thông thường về nghiệp vụ, một lớp chỉ nên chụi một trách nhiệm hoàn toạn cụ thể và rõ ràng, chánh sự kiêm nhiệm chức năng trong một lớp điều nãy sẽ dẫn đến những hậu quả của việc bảo trì code về sau này, cũng như làm ảnh hưởng đến việc mở rộng của phần mền trong tương lai. Nói một cách khác nó đã vi phạm nguyên lý số 1.
Nội dung:
Sự thay đổi diễn ra ở một lớp cụ thể chỉ phát sinh khi chức năng mà lớp đảm nhiệm có thay đổi
Nói cách khác đây là môt trong những khía cảnh mở rộng của nguyên lý số 1. Nó làm sáng tỏ việc chia tách lớp. Luôn bảo đảm rằng mỗi lớp chỉ được sinh ra để đảm bảo một chức năng cụ thể và nó chỉ tồn tại, phục vụ cho mục đích đó.
ii.6. Vài chú ý
- Tuy nhưng nguyên lý này mang tính kinh điển nhưng tất cả chỉ là những điều trong sách vở. Điều bạn cần làm là hiểu những gì bạn nên làm và làm những gì phù hợp với ngữ cảnh cụ thể của bạn. Bởi đây chỉ là những lý thuyết mang lại cho bạn thêm kiến thức, vấn để chủ yêu vẫn là tính hợp lý trong thiết kế.
- Một kinh nghiệm quan trọng là bạn nên tạo phong cách chuyên nghiệp cho mình ngay từ việc đặt tên, các thức quy ước các biên toàn cục, cục bộ các phương thức, comment code rõ ràng và mạch lạc, thống nhất tất cả trong phong cách code của bạn. Nếu bạn bí về tên hãy sử dụng các cụm từ như Info cho thực thể, Controller, Handle, Engine, Entity, Manger... cho các lớp của mình. Khi bạn có một lượng kiến thức khá khá về Design Pattern thì bạn có thể sử dụng các tên trong design pattern cho code của mình. Cố gắng đặt tên sáng sủa rõ ràng
Để bàn về nguyên lý trong thiết kế OO thì có rất nhiều, thôi xin không lan man nữa và sẽ tập chung vào vấn đề chính của chúng ta đó là các mẫu.
tiếp >>
No comments:
Post a Comment