Luật Demeter áp dụng như thế nào cho các hệ thống hướng đối tượng liên quan đến khớp nối và sự gắn kết? [đóng cửa]


15

Làm thế nào để Luật Demeter áp dụng cho các hệ thống hướng đối tượng với khớp nối và sự gắn kết?

Tôi đang đọc một cuốn sách "Phát triển phần mềm và thực hành chuyên nghiệp" và tình cờ thấy chương về LoD, và tò mò về cách áp dụng nguyên tắc đó vào các hệ thống hướng đối tượng.


Tôi đã từng thừa hưởng một dự án có mức độ khớp nối cao (cấu trúc liên kết sao). Tôi đã dọn dẹp mọi thứ bằng cách sử dụng 'Mẫu người hòa giải' để hạn chế khớp nối giữa các đối tượng và để người hòa giải nói chuyện với từng đối tượng thay thế. Mặc dù vẫn có khớp nối liên quan, nhưng nó giới hạn số lượng cá nhân được ghép. Một số người có thể muốn khám phá điều này thậm chí nhiều hơn nếu họ cảm thấy họ có vấn đề khớp nối cao với thiết kế của họ.
Jeach

Câu trả lời:


9

Theo Emerson Macedo , Luật Demeter quy định như sau:

  • Mỗi đơn vị chỉ nên có kiến ​​thức hạn chế về các đơn vị khác: chỉ các đơn vị "chặt chẽ" liên quan đến đơn vị hiện tại.
  • Mỗi đơn vị chỉ nên nói chuyện với bạn bè của mình; đừng nói chuyện với người lạ.
  • Chỉ nói chuyện với bạn bè ngay lập tức của bạn.

Điều này tương ứng trực tiếp với nguyên tắc khớp nối thấp vì các đơn vị (hoặc đối tượng) được cho là, giống như trên:

  • Không được gắn bó chặt chẽ với nhau. Chỉ những người gần nhất là.
  • Mỗi người chỉ nên nói chuyện với cộng tác viên của mình và không nói chuyện với cộng tác viên của cộng tác viên
  • Chỉ nói chuyện với đối tượng hợp tác ngay lập tức

Một trong những hình thức ghép thấp nhất là truyền thông điệp, tức là dữ liệu được chia sẻ giữa các đối tượng thông qua các cuộc gọi phương thức với các tham số.

Hơn nữa, từ những gì tôi có thể thấy, Luật Demeter không tương ứng trực tiếp với nguyên tắc gắn kết cao vì chỉ nêu rõ các đối tượng nên biết chính họ sở hữu dữ liệu gì. Một đối tượng có độ gắn kết thấp có các thành viên dữ liệu mà nó không sử dụng thường xuyên trong các phương thức riêng của mình. Nó là về nội dung của một đối tượng hơn là các mối quan hệ và đối tượng hợp tác của nó.


8

Khớp nối, đơn giản hóa

Khi một đối tượng gọi một phương thức, thuộc tính, v.v. của một đối tượng khác, chúng ta nói các đối tượng được ghép nối. Chúng tôi gọi nó là khớp nối vì bây giờ callee không thể thay đổi bất cứ điều gì về phương thức / prop riêng của nó. w.out phá vỡ người gọi .

Vì vậy, càng nhiều khớp nối - phương pháp, đạo cụ. - càng khó thay đổi mã callee mà không phá vỡ tất cả các mã sử dụng nó.

chiêm nghiệm khớp nối

  • Tham khảo ngay cả một prop., Phương thức kết hợp hai đối tượng.
  • Rõ ràng khớp nối là cần thiết để tạo ra phần mềm.
  • Với tính chất 'bước khóa' của khớp nối, chúng tôi muốn giới hạn và cô lập nó. Mục tiêu này chỉ đơn giản là đi cùng với nhà phát triển phần mềm nói chung. Nguyên tắc.
  • Càng ít đối tượng chúng ta phải nói chuyện, khớp nối càng thấp.
  • Nếu tôi cần thực hiện, giả sử, 20 phương thức gọi khác nhau thì khớp nối thấp hơn nếu tất cả 20 cuộc gọi đến một lớp / đối tượng, ngược lại các phương thức tương tự đó trải đều trên một số lớp / đối tượng.

Hầu hết các kiến ​​thức gây ra sự ghép đôi điên rồ

Ở đây chúng tôi có một Employeecái có Person'Địa chỉ'

public class Employee {
    public Person me = new Person();
}
public class Person {
    public Address home = new Address();
}
public class Address {
    public string street;
} 

Để có được đường phố tôi phải gọi : myEmployee.me.home.street. Điều này trái ngược 180 độ so với nguyên tắc ít kiến ​​thức nhất. Tôi phải biết gì về thiết kế, cấu trúc composite, của Employee, PersonAddresscác lớp học.

Thiết kế lớp bị lỗi này buộc tôi phải biết về tất cả các lớp đó và do đó kết hợp myEmployee.me.home.streettôi (đối tượng người gọi) với không dưới 3 lớp - chỉ nhận được một thuộc tính duy nhất!

Kiến thức ít nhất tiết kiệm trong ngày

Nếu tôi chỉ nói chuyện với Employeelớp tôi đang áp dụng nguyên tắc ít kiến ​​thức nhất, và bằng cách đó, chúng tôi sẽ tự động giới hạn khớp nối với chỉ lớp đó, đồng thời cách ly khớp nối với một lớp đó.

Bằng cách thêm tất cả các thuộc tính cần thiết trong Employeelớp, chúng tôi sửa lỗi khớp nối.

do đó

public class Employee {
    public Person me = new Person();
    public string street { return me.home.street; }
}

Cho phép tôi gọi: myEmployee.street-

  1. Tôi chỉ "biết" Employee
  2. Tôi được ghép nối với chỉ Employee- cho dù cấu trúc của nó phức tạp như thế nào.

Kiến thức kém nhất

Chúng tôi đã tách myEmployee khỏi PersonAddress, và lý tưởng nhất là chúng tôi nên tiếp tục áp dụng kiến ​​thức ít nhất bằng cách thêm thông qua các thuộc tính sao cho Employeechỉ nói chuyện PersonPersonchỉ nói chuyện vớiAddress


1

Nghiên cứu ( V. Basili, L. Briand và WL Melo. Xác thực các số liệu thiết kế hướng đối tượng là chỉ số chất lượng ) đã chỉ ra rằng các lớp có bộ phản hồi lớn hơn có xu hướng tạo ra nhiều lỗi hơn các lớp có bộ phản hồi nhỏ hơn vì bộ phản hồi nhiều hơn có nghĩa là cơ hội khớp nối cao hơn.

Giá trị của Law of Demeter là nó làm giảm phản ứng được đặt theo định nghĩa. Phương thức của một đối tượng chỉ có thể gọi một phương thức của chính nó, bất kỳ tham số nào được truyền vào phương thức, phương thức của bất kỳ đối tượng nào nó tạo và phương thức của bất kỳ đối tượng được giữ trực tiếp nào. Vì bộ phản hồi nhỏ hơn nên ít có khả năng khớp nối cao. Vì mô-đun / phương pháp chỉ sử dụng các tham chiếu có sẵn ngay lập tức nên có sự gắn kết cao hơn.


1
Nghiên cứu ( Anquetil, N. và Laval, J. Legacy Tái cấu trúc phần mềm: Phân tích một trường hợp cụ thể ) cũng đã chứng minh rằng việc giảm khớp nối và tăng sự gắn kết không phải lúc nào cũng mang lại chất lượng tốt hơn. Dựa vào kết quả của một nghiên cứu nhỏ, được coi là có hại.

0

Nó khá đơn giản; nói A phụ thuộc vào B và B phụ thuộc vào C. Nếu không có Luật Demeter, bạn có thể sử dụng cả B và C trong A nhưng bằng cách tuân thủ luật này, A chỉ phụ thuộc vào B, nó không thể phụ thuộc vào C.

Điều này cho phép ghép thấp vì nó làm giảm đáng kể số lượng phụ thuộc của mô-đun; sự gắn kết, mặc dù khác nhau về khái niệm từ khớp nối, đạt được theo cùng một cách. Bằng cách có ít phụ thuộc hơn vào một mô-đun, chúng trở nên cụ thể hơn cho mô-đun đó và do đó làm tăng sự gắn kết. Ngoài ra, tổng số mô-đun sẽ tăng lên và chúng sẽ trở nên chuyên biệt hơn để làm những thứ chuyên biệt cho mô-đun phụ thuộc (trái với các đối tượng thần) trực tiếp chuyển sang hệ thống mạch lạc hơn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.