Clean Code - Chapter 10: Classes | Trung Nguyễn Viết

Chapter 10: Classes

Class Organization (Tổ chức của Class)

Theo quy ước, Class nên bắt đầu với một danh sách các biến (variables). Hằng số tĩnh công khai (public static constants) nếu có nên để đầu tiên. Sau đó đến các biến tĩnh riêng tư (private static variables). Hiếm khi có một lý do tốt để đặt biến công khai (public variable).

Public functions nên được thực hiện theo danh sách các biến. Đặt các tiện ích riêng tư được gọi bởi một public funcion đặt ngay sau public function đó. Điều này tuân theo quy tắc Stepdown và giúp chương trình được đọc như một bài báo.

Encapsulation

Chúng tôi muốn giữ các biến và các chức năng tiện ích ở chế độ private, những cũng không nên cuồng tin quá về nó. Đôi khi chúng tôi giữ một biến hoặc chức năng tiện ích ở chế độ protected, do đó nó có thể được truy cập bởi một test. Đối với chúng tôi, test là nguyên tắc. Nếu một test ở trong cùng một package cần gọi một hàm hoặc truy cập vào một biến, chúng tôi sẽ để nó dạng protected hoặc package scope. Tuy nhiên, điều đầu tiên chúng ta làm là tìm kiếm một cách để duy trì sự riêng tư. Nới lỏng tính bao gói luôn là một cách thức cuối cùng.

=> List of variables: public static constants - private static variable - (public variable)

Classes Should Be Small

Nguyên tắc đầu tiên, các class nên được làm nhỏ. Nguyên tắc thứ hai, các class nên được làm nhỏ hơn nữa. Không, chúng ta sẽ không lặp lại chính xác những gì ở trong Chương Functions. Nhưng, cũng như Functions, nhỏ hơn là nguyên tắc đầu tiên khi nói đến thiết kế classes. Như Functions, câu hỏi trực tiếp được đặt ra luôn là "Nhỏ như thế nào?"

Với Functions, chúng ta đo lường bằng các đếm số dòng. Với Classes, chúng ta đo bằng cách khác, chúng ta đếm trách nhiệm.

Ví dụ về một class, SuperDashboard, với khoảng 70 public methods. Hầu hết các developer đều cho rằng nó có một siêu kích thước. Một số khác cho rằng nó như một "God class".

Tiếp theo cũng là SuperDashboard, nhưng chỉ chứa các phương pháp:

public class SuperDashboard extends JFrame implements MetaDataUser

public Component getLastFocusedComponent()

public void setLastFocused(Component lastFocused)

public int getMajorVersionNumber()

public int getMinorVersionNumber()

public int getBuildNumber()

}

Năm methods không phải là nhiều đúng không? Trong trường hợp này có thể xem như là vậy, nhưng mặc dù số lượng method nhỏ, tuy nhiên SuperDashboard lại có nhiều trách nhiệm.

Tên class nên mô tả trách nhiệm những gì mà nó đáp ứng. Thực tế, việc đặt tên có lẽ là cách đầu tiên giúp xác định quy mô của một lớp. Nếu chúng ta không thể lấy được một cái tên ngắn gọn cho lớp, sau đó nó có khả năng là class quá lớn. Với một cái tên mơ hồ cho class, nhiều khả năng là nó đã chịu nhiều trách nhiệm.

Chúng ta có thể viết mô tả ngắn gọn cho class với khoảng 25 từ, mà không sử dụng những từ ngữ như "nếu", "và", "hoặc" hay "nhưng".

The Single Responsibility Principle

Một class hoặc module nên có một và chỉ một lý do để thay đổi. Nguyên tắc này cho chúng ta một định nghĩa của trách nhiệm và cả chủ trương về quy mô của class. Class nên có một trách nhiệm - một lý do duy nhất để thay đổi.

Ví dụ ở trên thì class SuperDashboard có hai lý do để thay đổi. Đầu tiên, nó theo dõi thông tin các verson và dường như cần phải cập nhật mỗi khi phần mềm được vận chuyển. Thứ hai, nó quản lý thành phần Java Swing (một dẫn xuất của JFrame, Swing đại diện của một giao diện window ở cấp cao). Không nghi ngờ khi chúng ta sẽ cập nhật version number nếu chúng ta thay đổi bất cứ gì ở trong Swing code, nhưng theo chiều ngược lại thì không nhất thiết là đúng: chúng ta có thể thay đổi thông tin version dựa trên sự thay đổi code chỗ khác ở trên hệ thống.

Cố gắng đồng nhất trách nhiệm thường giúp chúng ta nhìn nhận được và tạo ra sự trừu tượng hóa tốt hơn trong code. Chúng ta dễ dàng lấy ra 3 method trong SuperDashboard phân phối thông tin của version để tách ra một class tên là Version. Lớp này có tiềm năng để sử dụng lại ở trong các ứng dụng khác!

public class Version {

public int getMajorVersionNumber()

public int getMinorVersionNumber()

public int getBuildNumber()

}

SRP là một trong những khái niệm quan trọng trong việc thiết kế hướng đối tượng. Nó cũng là một khái niệm đơn giản để hiểu và tuân thủ. Tuy nhiên, khó đỡ là SRP lại là nguyên tắc thường bị sỉ nhục nhất :)) Chúng tôi thường gặp phải những class mà làm quá nhiều thứ. Tại sao?

Để phần mềm chạy được và làm cho phần mềm sạch sẽ là hai việc hoàn toàn khác nhau. Hầu hết chúng ta đều bị giới hạn trong đầu là ưu tiên việc làm cho code chúng ta chạy được hơn là tổ chức và làm cho nó sạch sẽ. Điều này hoàn toàn phù hợp. Việc duy trì tách rời các quan hệ chỉ quan trọng khi chương trình của chúng ta hoạt động.

Vấn đề ở đây là có quá nhiều người trong chúng ta nghĩ rằng chúng ta chỉ đang thực hiện để chương trình hoạt động xong sau một lần. Chúng ta thất bại trong việc tổ chức lại và dọn dẹp chúng. Chúng ta chuyển sang các vấn đề khác hơn là trở lại và phá vỡ các lớp để nhồi nhét theo nguyên tắc mỗi class nên chịu một trách nhiệm duy nhất.

Đồng thời, nhiều developer lo ngại rằng một lượng lớn các class nhỏ với mục đích duy nhất sẽ làm khó khăn trong việc hiểu bức tranh tổng quát lớn. Họ lo lắng cho việc phải đi từ lớp này đến lớp khác để hiểu làm thế nào một mảnh lớn của công việc được hoàn thành.

Tuy nhiên hệ thống với nhiều class nhỏ cũng không di chuyển nhiều hơn so với ít class lớn là bao. Nó cũng nhiều như khi đọc hiểu một hệ thống với ít class lớn. Vậy nên câu hỏi ở đây là: Bạn muốn công cụ của bạn với nhiều ngăn kéo nhỏ, mỗi ngăn từng thành phần với khái niệm và nhãn hiệu riêng? Hay bạn muốn một ngăn kéo và tống khứ tất cả mọi thứ vào đó

Mỗi hệ thống lớn sẽ chứa đựng một số lượng lớn logic và độ phức tạp. Mục tiêu chính trong việc quản lý độ phức tạp như vậy là để tổ chức nó sao cho developer biết nơi để tìm thấy mọi thứ và chỉ cần hiểu được độ phức tạp của vấn đề cần tìm hiểu một cách tức thì. Ngược lại, một hệ thống với các class lớn và chứa đựng nhiều mục đích luôn cản trở chúng ta bằng cách cố bắt chúng ta lội qua rất nhiều thứ mà không nhất thiết cần phải biết ngay bây giờ.

=> Chúng tôi muốn hệ thống của chúng tôi hình thành bởi nhiều class nhỏ, không phải ít class nhưng to lớn. Mỗi class nhỏ tóm gọn bởi một trách nhiệm duy nhất, chỉ có một lý do duy nhất để thay đổi, tương tác với một vài đối tượng khác để đạt được trạng thái mà hệ thống muốn có.

Cohesion

Class nên có số lượng biến ít. Mỗi phương thức của một class nên thao tác với một hoặc nhiều biến đó. Mỗi biến ở trong class được sử dụng bởi mỗi phương thức nên có sự kết dính tối đa.

public class Stack {

private int topOfStack = 0;

List<Integer> elements = new LinkedList<Integer>();

public int size() {

return topOfStack;

}

public void push(int element) {

topOfStack++;

elements.add(element);

}

public int pop() throws PoppedWhenEmpty {

if (topOfStack == 0)

throw new PoppedWhenEmpty();

int element = elements.get(--topOfStack);

elements.remove(topOfStack);

return element;

}

Sự kết dính tối đa ở đây là các phương thức và các biến của class cùng phụ thuộc và có sự gắn kết với nhau như một tổng thể hợp lý.

Nói một cách đơn giản thì class nên hạn chế số lượng biến, và các method ở trong class đều sử dụng ít nhất một biến trong số này để gia tăng sự kết dính.

Maintaining Cohesion Results in Many Small Classes

Nếu chia function lớn thành nhiều function nhỏ hơn thì điều này đồng thời cùng làm gia tăng kích thước class. Giả sử rằng, function lớn với nhiều biến được khai báo ở trong nó. Bạn muốn trích một hàm nhỏ hơn thì hàm đó ra. Tuy nhiên code của bạn muốn sử dụng 4 biến được khai báo ở trong hàm. Bạn có cần phải pass cả 4 biến đó vào hàm mới như một tham số không?

Not at all! Nếu chúng ta để 4 biến đó vào biến chung của class, sau đó chúng ta có thể trích xuất code mà không cần pass bất kỳ biến nào ở đó. Nó thật dễ dàng để chia function ra thành các mảnh nhỏ.

Không may thay, điều đó làm cho class không còn được kết dính chặt chẽ nữa, bởi vì chúng ta càng ngày càng chất đống biến vào class trong khi chỉ một vài chức năng cần chia sẻ chúng.

Vậy nên, nếu một vài function muốn chia sẻ một số biến nhất định, tại sao chúng ta không tạo một class cho riêng chúng? Điều đó là tất nhiên, nếu class đã mất đi đoàn kết, hãy chia rẽ nó!

Organizing for Change

Đối với mọi hệ thống, sự thay đổi là liên tục. Mỗi sự thay đổi đều dẫn đến rủi ro về phần còn lại của hệ thống không còn hoạt động như dự định. Trong một hệ thống sạch, chúng ta tổ chức các class để làm giảm nguy cơ của sự thay đổi.

Ví dụ: Class Sql - Vi phạm SRP

public class Sql {

public Sql(String table, Column[] columns)

public String create()

public String insert(Object[] fields)

public String selectAll()

public String findByKey(String keyColumn, String keyValue)

public String select(Column column, String pattern)

public String select(Criteria criteria)

public String preparedInsert()

private String columnList(Column[] columns)

private String valuesList(Object[] fields, final Column[] columns)

private String selectWithCriteria(String criteria)

private String placeholderList(Column[] columns)

}

Sửa lại:

abstract public class Sql {

public Sql(String table, Column[] columns)

abstract public String generate();

}

public class CreateSql extends Sql {

public CreateSql(String table, Column[] columns)