CODE SMELLS

 BLOATERS................................................................................................................................. 2

 LONG METHOD.............................................................................................................................2

1. DẤU HIỆU.......................................................................................................................................2

2. NGUYÊN NHÂN VẤN ĐỀ....................................................................................................................2

3. CÁCH XỬ LÝ......................................................................................................................................2

4. PAYOFF...........................................................................................................................................3

5. PERFORMANCE..................................................................................................................................3

 LARGE CLASS..................................................................................................................................4

1. DẤU HIỆU NHẬN BIẾT.......................................................................................................................4

2. NGUYÊN NHÂN VẤN ĐỀ....................................................................................................................4

3. CÁCH XỬ LÝ......................................................................................................................................4

4. PAYOFF.............................................................................................................................................5

 PRIMITIVE OBSESSION.................................................................................................................5

1. DẤU HIỆU NHẬN BIẾT.....................................................................................................................5

2. NGUYÊN NHÂN VẤN ĐỀ..................................................................................................................5

3. CÁCH XỬ LÝ......................................................................................................................................6
 CODE SMELLS
• BLOATERS
• Long Method
1. Dấu hiệu
Một method chứa quá nhiều dòng code. Nhìn chung, bất cứ method nào dàu qúa 10 dòng
code nên được cân nhắc.

2. Nguyên nhân vấn đề

Giống như Hotel California, một cái gì đó luôn được thêm vào một method nhưng không bao
giờ đc lấy ra. Vì viết code thì dễ hơn đọc lại, nên “smell” này thường k được để ý tới cho tới
khi method trở thành một con quái vật quá khổ, xấu xí.
Về mặt tinh thần, viết thêm mã vào method hiện tại thì dễ hơn tạo mới 1 method: “Chỉ là 2
dòng nữa thôi mà, không cần thiết phải tạo mới toàn bộ 1 method cho việc đó…”. Điều đó có
nghĩa là một dòng code khác lại được thêm vào và lại dòng code khác tương tự, sinh ra một
mớ spaghetti code.

3. Cách xử lý
Theo nguyên tác, nếu cảm thấy cần cân nhắc về điều gì đó bên trong 1 method, bạn nên lấy
code này và đặt nó vào 1 method mới. Ngay cả 1 dòng code duy nhất cũng có thể và nên
được tách thành 1 method riêng biệt, nếu nó yêu cầu sự giải thích.
Và nếu method có tên mô tả, sẽ k ai cần nhìn vào code xem nó làm gì.
  Để giảm độ dài của method body, sử dụng Extract Method.
 Nếu biến và tham số local cản trở việc extract method, sử dụng Replace Temp with
Query, Introduce Parameter Object or Preserve Whole Object.
 Nếu k có cách nào bên trên, hãy thử chuyển toàn bộ method sang 1 object riêng biệt
thông qua Replace Method with Method Object.
 Các toán tử và vòng lặp là những đầu mối tốt để đưa sang 1 method riêng biệt.
Đối với lệnh điều kiện(if/switch), sử dụng Decompose Conditional.
Nếu có loop cản trở, dùng Extract Method.
4. Payoff
 Trong số các loại object-oriented code, các class có code ngắn thường tồn tại lâu nhất.
Các method hay chức năng càng dài càng khó hiểu và khó maintain.
 Thêm nữa, các method dài cung cấp nơi ẩn náy cho các code trùng lặp k mong muốn.

5. Performance
Việc tăng số lượng methods có làm ảnh hưởng đến hiệu suất như nhiều người khẳng định
không? Trong hầu hết các trường hợp, tác động là không đáng kể đến mức nó thậm chí không
đáng lo ngại.
Ngoài ra, bây giờ bạn đã có code rõ ràng và dễ hiểu, bạn có nhiều khả năng tìm thấy các
phương pháp thực sự hiệu quả để tái cấu trúc mã và nhận được hiệu suất thực sự nếu có
nhu cầu.

• Large Class
1. Dấu hiệu nhận biết
Một class chứa nhiều fields/methods/dòng code.

6. Nguyên nhân vấn đề

Class lúc bắt đầu thường nhỏ. Nhưng theo thời gian, chúng trở nên cồng kềnh khi chương
trình lớn dần.
Cũng như trường hợp của các methods dài, các lập trình viên thường thấy việc đặt một tính
năng mới vào một class hiện có sẽ ít chi phí hơn so với việc tạo một class mới cho tính năng
này.

7. Cách xử lý
Khi một class có quá nhiều chức năng, hãy nghĩ tới việc chia nhỏ nó ra:
 Extract Class hữu ích nếu một phần behavior của class to có thể đc tách thành cách
component riêng biệt.
 Extract Subclass hữu ích nếu 1 phần behavior của class lớn có thể đc implement theo
nhiều cách khác nhau hoặc chỉ đc dùng trong các case ít gặp.
 Extract Interface : nếu cần thiết có 1 danh sách các operations và behaviors mà
khách hàng có thể sử dụng.
 Nếu 1 class lớn chịu trách nhiệm về giao diện (graphical interface), bạn có thể di
chuyển 1 vài data và behavior của nó sang 1 domain object mới. Khi làm như vậy, có
thể cần lưu trữ các bản sao của 1 số data thành 2 nơi, và giữ cho data phải nhất quán.
Duplicate Observed Data cung cấp một cách để làm điều này.
8. Payoff
 Việc tái cấu trúc các lớp này giúp các nhà phát triển không cần phải nhớ một số lượng
lớn các thuộc tính của một lớp.
 Trong nhiều trường hợp, việc chia nhỏ các lớp lớn thành các phần sẽ tránh được sự
trùng lặp về mã và chức năng.

• Primitive Obsession
1. Dấu hiệu nhận biết
 Sử dụng các kiểu primitives thay vì các đối tượng nhỏ cho các tác vụ đơn giản (chẳng
hạn như tiền tệ, phạm vi, chuỗi đặc biệt cho số điện thoại, v.v.)
 Sử dụng hằng số để mã hoá thông tin (chẳng hạn như hằng số USER_ADMIN_ROLE
= 1 để đề cập đến người dùng có quyền quản trị viên.)
 Sử dụng hằng số chuỗi làm tên trường để sử dụng trong mảng dữ liệu.

9. Nguyên nhân vấn đề

Giống như hầu hết các “smell” khác, những ám ảnh primitive được sinh ra trong những
khoảnh khắc yếu đuối. "Chỉ là một trường để lưu trữ một số dữ liệu!" lập trình viên cho biết.
Tạo một trường nguyên thủy dễ hơn nhiều so với tạo một lớp hoàn toàn mới, phải không? Va
nó được thực hiê ̣n. Sau đó, một trường khác là cần thiết và được thêm vào theo cách tương
tự. Và kìa, class trở nên khổng lồ và khó sử dụng.

Primitives thường được sử dụng để làm kiểu "mô phỏng". Vì vậy, thay vì một kiểu dữ liệu
riêng biệt, bạn có một tập hợp numbers hoặc strings tạo thành danh sách các giá trị được phép
cho các enitity. Các tên dễ hiểu sau đó được đặt cho các số và chuỗi cụ thể này thông qua các
hằng số, đó là lý do tại sao chúng được lan truyền rộng rãi.

Một ví dụ khác về việc sử dụng là field simulation. Class chứa một mảng lớn dữ liệu đa dạng
và các hằng số strings (được xác định trong lớp) được sử dụng làm chỉ số mảng để lấy dữ liệu
này.

10. Cách xử lý
 Nếu bạn có nhiều trường nguyên thủy, có thể nhóm hợp lý một số trường thành lớp
riêng của chúng. Tốt hơn nữa, hãy chuyển cả hành vi được liên kết với dữ liệu này
vào lớp. Với task này, sử dụng Replace Data Value with Object

 Nếu giá trị của các trường nguyên thủy được sử dụng trong các method
parameters, thì dùng Introduce Parameter Object or Preserve Whole Object.
 Khi dữ liệu phức tạp được code trong các biến, sử dụng Replace Type Code
with Class, Replace Type Code with Subclasses or Replace Type Code with
State/Strategy.
 Nếu có các mảng trong số các variables, dùng Replace Array with Object.
11. Payoff
 Code trở nên linh hoạt hơn nhờ sử dụng các đối tượng thay vì các
primitives.
 Khả năng hiểu và tổ chức mã tốt hơn. Các thao tác trên dữ liệu cụ thể ở cùng
một nơi, thay vì bị phân tán. Không còn phải đoán về lý do của tất cả các
hằng số kỳ lạ này và tại sao chúng nằm trong một mảng.
 Dễ dàng tìm thấy duplicate code.
REFACTORINGS TECHNIQUES
Composing Methods
Phần lớn việc tái cấu trúc được dành cho các phương pháp composing
methods. Trong hầu hết các trường hợp, các methods quá dài là gốc rễ
của mọi vấn đề. Sự mơ hồ của code bên trong các phương thức này che
giấu logic thực thi và làm cho phương thức cực kỳ khó hiểu — và thậm
chí còn khó thay đổi hơn.
Các kỹ thuật refactoring trong nhóm này hợp lý hóa các methods, loại
bỏ sự trùng lặp code và mở đường cho những cải tiến trong tương lai.
 Extract Method
 Inline Method
 Extract Variable
 Inline Temp
 Replace Temp With Query
 Split Temp Variable
 Remove Assignments To Parameters
 Replace Method With Method Object
 Substitute Algorithm
Moving Features between Objects
Ngay cả khi bạn đã phân phối các chức năng giữa các lớp khác nhau
theo cách kém hoàn hảo thì vẫn có hy vọng.
Các kỹ thuật tái cấu trúc này chỉ ra cách di chuyển chức năng giữa các
lớp một cách an toàn, tạo các lớp mới và ẩn các chi tiết triển khai khỏi
quyền truy cập công khai.
 Move Method
 Move Field
 Extract Class
 Inline Class
 Hide Delegate
 Remove Middle Man
  Introduce Foreign Method
 Introduce Local Extension
Organizing Data
Các kỹ thuật tái cấu trúc này giúp xử lý dữ liệu, thay thế các primitives
bằng các class mang nhiều tính chức năng.
Một kết quả quan trọng khác là gỡ rối các liên kết lớp, điều này làm
cho các lớp dễ di động hơn và có thể tái sử dụng.
 Change Value to Reference
 Change Reference to Value
 Duplicate Observed Data
 Self Encapsulate Field
 Replace Data Value with Object
 Replace Array with Object
 Change Unidirectional Association to Bidirectional
 Change Bidirectional Association to Unidirectional
 Encapsulate Field
 Encapsulate Collection
 Replace Magic Number with Symbolic Constant
 Replace Type Code with Class
 Replace Type Code with Subclasses
 Replace Type Code with State/Strategy
 Replace Subclass with Fields
Simplifying Conditional Expressions
Các điều kiện có xu hướng ngày càng trở nên phức tạp hơn trong logic
của chúng theo thời gian, và vẫn có nhiều kỹ thuật hơn để chống lại
điều này.
 Consolidate Conditional Expression
 Consolidate Duplicate Conditional Fragments
 Decompose Conditional
 Replace Conditional with Polymorphism
 Remove Control Flag
 Replace Nested Conditional with Guard Clauses
  Introduce Null Object
 Introduce Assertion
Simplifying Method Calls
Những kỹ thuật này làm cho việc gọi phương thức trở nên đơn giản
và dễ hiểu hơn. Điều này, đơn giản hóa các interfaces cho sự tương
tác giữa các lớp.

 Add Parameter
 Remove Parameter
 Rename Method
 Separate Query from Modifier
 Parameterize Method
 Introduce Parameter Object
 Preserve Whole Object
 Remove Setting Method
 Replace Parameter with Explicit Methods
 Replace Parameter with Method Call
 Hide Method
 Replace Constructor with Factory Method
 Replace Error Code with Exception
 Replace Exception with Test
Dealing with Generalization
Tính trừu tượng có một nhóm kỹ thuật tái cấu trúc riêng, chủ yếu liên
quan đến việc di chuyển chức năng dọc theo hệ thống phân cấp kế thừa
lớp, tạo ra các classes và interfaces mới, đồng thời thay thế kế thừa
bằng ủy quyền và ngược lại.
 Pull Up Field
 Pull Up Method
 Pull Up Constructor Body
 Push Down Field
 Push Down Method
 Extract Subclass
 Extract Superclass
 Extract Interface
 Collapse Hierarchy
 Form Template Method
 Replace Inheritance with Delegation
 Replace Delegation with Inheritance