[ SOLID là gì ] Nguyên tắc 1: Đơn nhiệm – Single Responsibility principle (SRP).

      Tất cả developer chúng ta đều biết viết code – đó là điều đương nhiên, tuy nhiên không phải ai cũng biết viết code sao cho đẹp và chuẩn, và không phải ai cũng hiểu được khái niệm “chuẩn” là như thế nào trong việc phát triển phần mềm. SOLID xuất hiện như là một trong những định hướng giúp các developer thiết kế hệ thống và phát triển phần mềm “chuẩn” hơn: code chạy tốt và trong sáng, dễ dàng mở rộng, dễ bảo trì trong tương lai, … SOLID là một trong những nguyên lí phát triển phần mềm sẽ được hỏi trong hầu hết các buổi phỏng vấn việc làm, nó cũng là nguyên lí mà tất cả các dev chúng ta nên biết và áp dụng nếu muốn cải thiện kĩ năng của bản thân. SOLID gồm 5 nguyên lí chính:

  1. Single Responsibility principle.
  2. Open-Closed principle.
  3. Liskov substitution principle.
  4. Interface segregation principle.
  5. Dependency inversion principle.

       Nói ngắn gọn thì đây là nguyên lí rất quan trọng trong lập trình, vì thế mà mình quyết định sẽ tìm hiểu và chia sẻ cho mọi người. Bạn có thể tìm hiểu tổng quan về SOLID ở bài viết này. Hôm nay mình sẽ đi sâu phân tích nguyên lí đầu tiên: Đơn nhiệm – Single responsibility principle (SRP). Bắt đầu nào!

Nguyên tắc thứ nhất nói gì

        Phát biểu: Mỗi lớp chỉ nên chịu trách nhiệm về một nhiệm vụ cụ thể nào đó mà thôi.

        Nguyên tắc này nói về việc: đơn nhiệm. Để hình dung một các đơn giản, nếu bạn là một người phát triển phần mềm, thì bạn nên tập trung vào việc viết code và các vấn đề liên quan đến phần mềm, các việc lặt vặt như lau dọn văn phòng, đóng mở cửa văn phòng .v.v.. thì hãy để cho người khác làm ( ví dụ như công ty sẽ thuê người lao công để làm các việc này). Phân công công việc theo chuyên môn như thế vừa giúp bạn tập trung vào công việc để đạt được hiệu quả cao, vừa giúp văn phòng sạch sẽ hơn (vì người lao công sẽ lau dọn sạch hơn bạn ^^).

        Nguyên lí này không chỉ áp dụng cho lĩnh vực IT và cho hầu hết mọi điều trong cuộc sống: mọi thứ chỉ nên tập trung vào chuyên môn của mình, nếu bạn ôm đồm quá nhiều việc một lúc thì kết quả đạt được sẽ không cao. Tấm hình sau minh hoạ cho việc này:

機能_1459687110 (1)
Hình 1 – Dụng cụ đa năng có thể làm được rất nhiều việc, thế nhưng …

        Thế nhưng hãy thử xem xét, sẽ ra sao nếu bạn muốn dùng dao để cắt một trái dưa hấu, sẽ ra sao nếu như bạn muốn dùng kéo để cắt một tấm băng rôn bự, sẽ ra sao nếu bạn muốn cưa cái cây sau nhà …

       Chắc hẳn là những dụng cụ all-in-one – tất cả trong một – sẽ không thể làm được những điều này rồi, bạn sẽ cần những dụng cụ to lớn hơn và mạnh mẽ hơn. Và như vậy, bạn cần phải tách riêng từng bộ phận theo công dụng chứ không còn gom chung vào all-in-one được nữa. Đây chính là sức mạnh của tính đơn nhiệm.

Trong phần mềm thì nguyên tắc này trông ra sao?

        Trong phần mềm cũng vậy, khi bạn thiết kế một phần mềm, để cho việc bảo trì và mở rộng dễ dàng sau này, bạn nên thiết kế theo hướng đơn nhiệm: mỗi lớp chỉ nên chịu trách nhiệm về một tính năng duy nhất. Nếu xuất hiện đoạn code mà không thuộc về trách nhiệm của lớp, thì nên tách đoạn code đó ra một lớp xử lí khác.

        Hãy xem một ví dụ sau, chúng ta có một lớp học sinh với các hàm đơn giản như lấy thông tin học sinh, nộp đơn học bổng, …

class Student
{
    string name;
    int age;

    string getStudentInfoJson()
    {
        return json_encode( array(name, age) );
    }

    string getStudentInfoHtml()
    {
        return "<span> Name: " + name + ", age: " + age + "</span>";
    }

    int applyForScholarship()
    {
        try
        {
            // do something here
        }
        catch
        {
            //write error to log file
            system.Out.print("Error_log.txt", "Error getting scholarship!");
        }
    }
}

Nếu thiết kế lớp học sinh như vậy thì đã ổn chưa nhỉ?

       Tất nhiên, đoạn code trên có thể chạy đúng yêu cầu của phần mềm. Thế nhưng! Dường như lớp Student đang ôm đồm quá nhiều việc thì phải: cung cấp thông tin cá nhân, định dạng cấu trúc của thông tin cá nhân, ghi log, apply xin học bổng ..v.v.. Điều này vi phạm quy tắc đơn nhiệm. Về mặt logic xử lí, có một số câu hỏi mà chúng ta có thể thắc mắc: học sinh thì có nhiệm vụ gì mà phải đi định dạng dữ liệu nhỉ? Học sinh thì sao lại có nhiệm vụ ghi log nhỉ? Nếu ta thay đổi cách ghi log hoặc đổi định dạng format thông tin thì thế nào? …

        Áp dụng quy tắc đơn nhiệm của SOLID, sẽ tốt hơn nếu ta xây dựng thêm các lớp riêng biệt làm nhiệm vụ format data và ghi log. Chúng ta sẽ thực hiện refactor lại đoạn code ở trên, code mới trông sẽ như thế này:

class Student
{
    string name;
    int age;

    string getName()
    {
        return name;
    }

    int getName()
    {
        return age;
    }

    bool applyForScholarship()
    {
        try
        {
            // do something here
        }
        catch
        {
            ExportLog log_control = new ExportLog();
            log_control.exportLogToFile( "error_log.txt", "Error getting scholarship");
        }
    }
}

class Formatter()
{
    string formatInfoJson(string name, int age)
    {
        return json_encode( array( name, age ) );
    }

    string getStudentInfoHtml(string name, int age)
    {
        return "<span> Name: " + name + ", age: " + age + "</span>";
    }
}

class ExportLog
{
    void exportLogToFile(string filename, string error)
    {
        //write error to log file
        system.Out.print( filename, error );
    }
}

        Như bạn thấy đó, việc tách bạch nhiệm vụ giữa các lớp khiến code trở nên rành mạch, dễ đọc, dễ bảo trì và mở rộng hơn rất nhiều. Sẽ dễ dàng để mở rộng ra các cách format mới sau này, hoặc cũng rất dễ để  đáp ứng yêu cầu về nhiều cách xuất log hơn nữa khi chương trình được mở rộng. Bạn thấy đó, áp dụng các quy tắc SOLID vào thiết kế chương trình là cho phần mềm của chúng ta “tốt” hơn rất nhiều phải không nào.

Kết luận

        Về mặt kĩ thuật mà nói, đoạn code trên vẫn còn có thể trở nên tốt hơn nữa nếu chúng ta áp dụng các kĩ thuật khác trong SOLID, nhưng mình chỉ đang muốn nhấn mạnh ở đây tính đơn nhiệm của chương trình.

       Bạn thấy đó, chúng ta mới chỉ áp dụng một quy tắc đầu tiên của SOLID – quy tắc đơn nhiệm – vào thiết kế phần mềm thì code đã trở nên trong sáng và hữu dụng hơn rất nhiều. Có thể dễ dàng hình dung được, nếu các anh em developer chúng ta đều nắm vững và áp dụng các quy tắc này, thì phần mềm của chúng ta sẽ tốt lên rất nhiều.

       Nếu có một điều gì đó để khuyên mọi người, mình chỉ muốn nói: hãy dùng SOLID 🙂

7 thoughts on “[ SOLID là gì ] Nguyên tắc 1: Đơn nhiệm – Single Responsibility principle (SRP).

  1. Pingback: [Giới thiệu sách] The art of readable code – Cái tên đã nói lên tất cả – Webbynat

  2. Pingback: Tìm hiểu SOLID để trở thành Dev chất! – Webbynat

  3. Pingback: [ SOLID là gì ] Nguyên tắc 2: Đóng và Mở – Open / Closed principle (OCP) – Webbynat

  4. Pingback: [ SOLID là gì ] Nguyên tắc 3: Tính khả dĩ thay thế – Liskov substitution principle (LSP) – Webbynat

  5. Pingback: [ SOLID là gì ] Nguyên tắc 4: Chia nhỏ interface – Interface segregation principle (ISP) – Webbynat

  6. Pingback: [ SOLID là gì ] Nguyên tắc 5: Tính tương thích động – Dependency Inversion principle (DIP) – Webbynat

  7. Pingback: [ Giới thiệu sách ] The pragmatic programmer – Lập trình viên … tiêu biểu. (P2) – Những dòng code vui

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s