Tag: OOP Designing

Ví dụ về SOLID trong OOP

~ namdh ~ Leave a comment

SOLID là tập hợp 5 nguyên tắc thiết kế các lớp trong OOP, tuân thủ các nguyên tắc này sẽ giúp bạn tạo thiết kế dễ thay đổi, mở rộng, dễ kiểm soát lỗi về sau. Đây là các nguyên tắc mà từ anh fresher tới anh lập trình sư, và cho đến ngày code cuối cùng trước khi xuống lỗ bạn vẫn phải tuân theo (chứ không đến khi con cháu thừa kế lại code ngày nào nó cũng lôi ra chửi 😁).

Vấn đề là làm sao để các bạn hiểu đúng và đầy đủ 5 nguyên tắc này. Tôi đã cố gắng suy nghĩ, tâm tư, tìm hiểu… kể cả lúc đi ăn và đi… ngủ, để tìm xem cách nào giúp các bạn hiểu và nhớ các quy tắc này dễ dàng nhất. Và cách tôi chọn là viết ra 5 ví dụ mẫu, đại diện cho việc vi phạm 5 quy tắc trên.

Các bạn có thể truy cập vào các ví dụ trên tại: https://github.com/daohainam/solid-bad-designs

Cách học là:

– Bạn hãy đọc qua code của từng ví dụ, tốt nhất là theo thứ tự các chữ cái đầu tiên S-O-L-I-D.

– Tự mình suy nghĩ xem có vấn đề gì với thiết kế trên. Bạn nên đặt ra các câu hỏi kiểu như: “Nếu sau này ta muốn thêm”, “Nếu sau này ta muốn thay đổi” … thì phải làm sao?

– Từ đó bạn xem thử khi bạn muốn thêm/thay đổi như vậy thì sẽ gặp vấn đề gì.

– Thử thay đổi lại thiết kế các lớp để giúp thiết kế tốt hơn, giúp giải quyết các vấn đề của bạn.

Chủ đề về phân tích thiết kế là một chủ đề rất thú vị các bạn ạ. Trong thực tế bạn sẽ luôn gặp những vấn đề mà lúc đi học có nằm mơ cũng không tưởng tượng ra được 😀. 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ĩ…

Tôi sẽ cập nhật thêm mô tả các vấn đề và giải pháp. Các bạn nhớ truy cập vào repository và tặng cho nó 1 Star nếu thấy hay nhé, xin cảm ơn trước! 😘

Tại sao chúng ta phải vẽ ra các sơ đồ khi thiết kế ứng dụng?

~ namdh ~ Leave a comment

Các sơ đồ (class, sequence, E-R, database…) được vẽ ra để:

– Trực quan hóa: giúp người thiết kế dễ dàng nhìn thấy các thực thể, các mối quan hệ, tìm ra các vấn đề có thể xảy ra và xây dựng bước thiết kế tiếp theo.

– Xây dựng tài liệu giúp tra cứu lại sau này, giúp các thành viên mới tham gia vào dự án có thể hiểu được.- Trao đổi thông tin giữa các thành viên trong dự án khi thiết kế.

ℹ️ 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ế.

Continue reading “Tại sao chúng ta phải vẽ ra các sơ đồ khi thiết kế ứng dụng?” →

Khi nào bạn bắt đầu có thể học về thiết kế?

~ namdh ~ Leave a comment

Có một số bạn nhắn tin hỏi về công việc thiết kế, cũng như cần chuẩn bị gì để học, trong bài này tôi sẽ gom chung một số câu hỏi thường gặp nhất dành cho các bạn quan tâm.

👉 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.

👉 Công việc của nhà thiết kế phần mềm là gì? Một nhà thiết kế thông thường vẫn là một developer, hàng ngày anh ta vẫn phải code, test, debug… Có lẽ hiếm có nhà thiết kế nào chỉ làm mỗi công việc thiết kế, vì 2 lẽ:- Công việc thiết kế thường không chiếm nhiều thời gian so với các phần việc khác, vẽ ra một component, cùng các class bên trong nhanh hơn nhiều so với code/test/debug/release/doc nó.- Các phần việc còn lại (code/test/debug/release/doc) cũng thực sự phức tạp, thiếu hiểu biết về chúng sẽ dẫn đến việc thiết kế ra các mô hình không thực tế, cũng như không thấy được những khó khăn có thể gặp phải. Vậy nên bạn vẫn phải làm công việc của một developer để cập nhật các kỹ năng trên. Thật sự muốn trở thành một nhà thiết kế giỏi, bạn cũng phải là một nhà phát triển giỏi, nhưng không nhất thiết phải chờ đến khi lập trình giỏi thì mới bắt đầu học thiết kế – bạn hoàn toàn có thể học song song cả hai.

Continue reading “Khi nào bạn bắt đầu có thể học về thiết kế?” →

LÀM QUEN VỚI PHÂN TÍCH THIẾT KẾ

~ namdh ~ Leave a comment

Một trong những câu hỏi tôi luôn suy nghĩ trong đầu khi bắt đầu bước vào ngành phần mềm là làm thế nào để từ một bài toán thực tế ta có thiết kế ra được các thành phần bên trong một cách đúng đắn: DLL, class, property… Tôi tin rằng các bạn cũng có cùng câu hỏi như vậy, có một kiến thức tốt về thiết kế không chỉ giúp cho công việc hiện tại mà còn mở ra một chân trời mới trong con đường sự nghiệp của bạn.Loạt bài này sẽ giúp bạn có được những kiến thức vững chắc về thiết kế phần mềm, và vì có khá nhiều vấn đề liên quan đến thiết kế nên tôi sẽ viết ra thành nhiều bài theo thứ tự, các bạn chịu khó theo dõi nhé.

Trước khi bắt đầu, ta cần thống nhất với nhau vài điều:

– Kiến thức về OOP là bắt buộc, các phương pháp thiết kế ở đây đều yêu cầu một nền tảng tốt về OOP ❗️.

– Tôi sẽ không viết riêng cho một nền tảng hay ngôn ngữ nào, nhưng sẽ tập trung vào Java và .NET, cùng các ngôn ngữ là Java và C#. Đây là hai trong những nền tảng phổ biến và tốt nhất, đặc biệt cho việc xây dựng các ứng dụng lớn.

– UML: Bạn không cần biết trước về UML, nhưng nếu có kiến thức về nó sẽ rất tốt, đôi khi tôi có thể dùng nó để mô tả.

Continue reading “LÀM QUEN VỚI PHÂN TÍCH THIẾT KẾ” →

VÀI ĐIỀU VỀ OOP DESIGNING

~ namdh ~ Leave a comment

Ở trong bài OOP – chủ đề huyền thoại trong các cuộc phỏng vấn tuyển dụng tôi có nhắc đến OOP designing, trong bài này tôi sẽ nói kỹ hơn về nó.

Hầu hết chúng ta khi nhắc đến OOP đều chỉ nhớ là nó có 3 (hoặc 4) thuộc tính: đóng gói, thừa kế, đa hình và trừu tượng. Thực chất đó chỉ là những công cụ và nguyên liệu, cái quan trọng nhất vẫn là từ những công cụ và nguyên liệu này, bạn sẽ xây nên ngôi nhà như thế nào. Đó cũng là sự khác nhau giữa ông thợ xây và kiến trúc sư, giữa coder và designer. Muốn lên một trình cao hơn, ta cần biết cách sử dụng chúng một cách đúng đắn, và người xưa đã đúc kết ra một số quy tắc. Ta hãy cùng xem qua những nguyên tắc (nếu là một bậc thầy marketing thì sẽ thêm từ “bí mật” 🤮) nhé:

👉 Danh từ tạo nên lớp và thuộc tính, động từ tạo nên phương thức: Có lẽ nhiều người sẽ ngạc nhiên về điều này, nhưng thực ra, viết mô tả các chức năng hệ thống luôn phải là công việc đầu tiên khi thiết kế.

Hãy xem câu sau: “Người dùng nhập họ tên và email để đăng ký, hệ thống sẽ kiểm tra xem Email đã có trong hệ thống hay chưa, nếu có rồi sẽ hiển thị thông báo lỗi, nếu chưa có sẽ lưu vào cơ sở dữ liệu và gửi email chúc mừng đến người dùng vừa đăng ký.”

Trong đoạn văn trên, ta dễ dàng nhận ra một số danh từ: Người dùng, họ tên, email, hệ thống, cơ sở dữ liệu… và một số động từ: đăng ký, kiểm tra (email), hiển thị (thông báo lỗi), lưu (vào CSDL), gửi (email chúc mừng)…

Các danh từ có giá trị đơn (họ tên, email…) sẽ là thuộc tính (property), các danh từ chứa các thuộc tính sẽ là class.Đây là một quy tắc chung, giúp bạn không sai hướng khi phải làm việc với vô số thông tin đầu vào, và bạn có thể bám sát được đề bài. Sau bước này bạn sẽ có một danh sách thô, bạn sẽ phải tinh chỉnh, xem xét cái nào thừa, cái nào thiếu, nhóm chung các lớp cùng chức năng vào chung module… Ở bước này đòi hỏi kỹ năng và kinh nghiệm cửa người thiết kế khá nhiều, và không có cách nào khác là bạn phải thực hành, và tham khảo các dự án nguồn mở.

Continue reading “VÀI ĐIỀU VỀ OOP DESIGNING” →