Nguyên tắc Demeter trong hướng đối tượng

Mở bài

Là dân lập trình, chắc hẳn các bạn cũng từng ít nhất một lần nghe đến Law of Demeter (LoD), tạm dịch là Nguyên tắc Demeter, còn được gọi là nguyên tắc Một dấu chấm.

Thân bài

Law of Demeter là gì?

Trong thần thoại Hy Lạp, Demeter là vị nữ thần của nông nghiệp, mùa màng và thiên nhiên.

Tuy nhiên nữ thần Demeter không định ra và cũng không liên quan lắm đến nguyên tắc Demeter mà chúng ta đang nói ở đây cả.
Chuyện xưa kể rằng vào mùa thu năm 1987, tại Đại học Northeastern Mỹ, trong một cuộc thảo luận của dự án Demeter (một dự án nhằm giúp việc phát triển phần mềm trở nên dễ dàng hơn), nguyên tắc Demeter lần đầu tiên đã được đề ra, nhằm mục đích tối thiểu hóa sự phụ thuộc lẫn nhau (loose coupling) của các thành phần trong ứng dụng. Cái tên Law of Demeter được sinh ra từ đó.
Cơ bản thì Law of Demeter chỉ có một nguyên tắc.

Only talk to your immediate friends, tạm dịch là "Chỉ chơi với những người thân bằng quyến thuộc."

hoặc

Don't talk to strangers, nôm na là "Đừng chơi với người lạ mặt"

Cắt nghĩa LoD bằng ngôn ngữ Địa Cầu

Nếu đã đọc bản dịch mà bạn vẫn chưa hiểu LoD là gì thì chúc mừng, bạn vẫn còn ở Trái Đất.
Giả sử ta có câu nói sau

"Tôi nhờ má tôi qua năn nỉ cô hàng xóm dọa nạt chồng cô ấy dạy bảo lại đứa con đừng thả chó ra cắn tôi nữa"

Câu nói trên đã vi phạm Nguyên tắc Demeter.

• Mục tiêu của tôi là khiến con chó biến mất, và tôi biết má tôi có thể làm điều đó.
• Má tôi có quen với cô hàng xóm và tin rằng cô ta sẽ có khả năng biến mất con chó.
• Thật sự má tôi không hề biết rằng cô hàng xóm có chồng, và cũng không quan tâm cô ta làm biến mất con chó bằng cách nào.
• Cô hàng xóm cũng không ngờ con cô ta mới là đứa thả chó.

Với nguyên tắc Demeter, ta có thể viết lại thành:

"Tôi nhờ má tôi làm biến mất con chó."
"Má tôi qua năn nỉ cô hàng xóm đừng thả chó."
"Bị mắng vốn, cô hàng xóm chửi chồng và bảo anh ta đừng thả chó nữa."
"Người chồng hằn học bảo đứa con: Con có dẹp con chó ngay không thì bảo?"
"Đứa bé xích con chó lại."

Vì sao phải tuân theo LoD?

Giả sử bạn có một đoạn code sau

objectA.getObjectB().getObjectC().doSomething();

Nhìn thoáng qua thì ta thấy đoạn code trên hết sức ... "bình thường". Tuy nhiên nó vi phạm nguyên tắc Demeter và có thể gây chút phiền phức cho bạn sau này.

• objectA về sau có thể sẽ không truy cập ObjectC qua ObjectBnữa.
• Phương thức doSomething() trong ObjectC có thể sẽ không còn tồn tại nữa.
• Các loại lỗi nhưNullPointerException, NoMethodErrorsẽ văng ra nếu như ObjectB và ObjectC bị null.
• Khi đóng gói objectA để tái sử dụng, bạn sẽ cần phải kèm ObjectB, ObjectC với nó. => Sự phụ thuộc lẫn nhau giữa các thành phần trong hệ thống tăng cao. (tightly coupled)

Ví dụ về ứng dụng LoD

Giả sử bạn có đoạn code sau:

user.posts.order("created_at DESC").first

Ví dụ ta có thể viết lại thành

class User
  def latest_post
    latest_posts.first
  end

  def latest_posts
    posts.latest
  end
end

class Post
  def self.latest
    order("create_at DESC")
  end
end

# => user.latest_post

Kết bài

Thiết nghĩ cái gì thì có cũng mặt tốt và mặt xấu của nó cả, việc tuân theo LoD cũng vậy.

Mặt tốt

Tất nhiên là nếu học tập và làm việc theo nguyên tắc Demeter, ta sẽ có được những lợi ích rất rõ ràng.

• Class sẽ loosely coupled hơn, những thành phần trong hệ thống sẽ ít phụ thuộc nhau hơn.
• Đóng gói và tái sử dụng sẽ dễ dàng hơn.
• Việc test sẽ dễ hơn nhiều, phần setup của test sẽ đơn giản hơn.
• Quản lý lỗi sẽ bớt rối rắm hơn.

Mặt xấu:

• MỆT, nếu như trước ta chỉ cần gõ getA().getB().getC().doSomeThing() thì giờ đây bạn sẽ phải viết một đống phương thức kiểu proxy để thỏa mãn LoD.
• Đặt tên cho phương thức đôi khi là một việc hết sức NHỨC ÓC. Sẽ có những hàm hết sức dài dòng luộm thuộm như user.oldest_posts_published_in_the_past_three_days

Tuy nhiên vì mục tiêu to lớn là một hệ thống tốt, thì ngại-gì-vết-bẩn các bạn nhỉ?

Nguồn: https://kipalog.com/posts/Nguyen-tac-Demeter-trong-huong-doi-tuong