Làm thế nào để sửa đổi mã để nó tuân thủ Luật Demeter

Question

public class BigPerformance 
{ 
    public decimal Value { get; set; } 
} 

public class Performance 
{ 
    public BigPerformance BigPerf { get; set; } 
} 

public class Category  
{ 
    public Performance Perf { get; set; }  
} 

Nếu tôi gọi:

Category cat = new Category(); 
cat.Perf.BigPerf.Value = 1.0; 

Tôi giả định này này phá vỡ Law of Demeter/Principle of Least Knowledge?
Nếu vậy, làm thế nào để khắc phục điều này nếu tôi có một số lượng lớn các thuộc tính lớp bên trong?

Answer 1

Điều này không vi phạm Luật Demeter vì bạn đang sử dụng hợp đồng công khai các lớp học.

Answer 2

Nếu bạn đang nói về Luật Demeter như trong "đừng gọi những người hàng xóm của hàng xóm", bạn có thể ủy thác nó cho các phương pháp khác để làm những gì bạn muốn.

Từ ví dụ của bạn, tôi đoán bạn muốn đặt lại giá trị hiệu suất hoặc thứ gì đó. Bạn có thể sửa đổi các mã ví dụ vì vậy họ đang bị xích vốn thay vì:

Category cat = new Category(); 

cat.resetPerf(); 

Mã này sẽ là một cái gì đó tương tự như thế này:

public class BigPerformance 
{ 
    //constructors 'n stuff 

    public static decimal DEFAULT; 

    public decimal Value {get; private set;} 

    public void reset() { 
     Value = BigPerformance.DEFAULT; 
    } 
} 

public class Performance 
{ 
    //constructors 'n stuff 

    private BigPerformance BigPerf {get; set}; 

    public reset() { 
     BigPerf.reset(); 
    } 
} 

public class Category 
{ 
    // constructors 'n stuff 

    public Performance Perf {get; private set;} 

    public resetPerformance() { 
     Perf.reset(); 
    } 
} 

Bằng cách đó lớp Category không cần phải biết làm thế nào để thiết lập lại giá trị trong trường hợp giá trị mặc định là một cái gì đó khác hoặc loại của nó được thay đổi trong tương lai.

Cá nhân nếu rủi ro thay đổi thấp, tôi sẽ thay thế cho số juharr's answer.

Answer 3

Category cat = new Category(); 
cat.Perf.BigPerf.Value = 1.0; 

là

Category cat = new Category(); 
cat.GetPerf().GetBigPerf().SetValue(1.0); 

Vì vậy, nó là phá vỡ các quy tắc nếu định nghĩa wikipedia là đúng:

.. [M] ethod M của một đối tượng O có thể chỉ gọi các phương thức sau đây: các loại đối tượng:

• O tự
• thông số M
• bất kỳ đối tượng được tạo/instantiated trong M
• thành phần trực tiếp O của các đối tượng
• một biến toàn cầu, truy cập bằng O, trong phạm vi của M

Đặc biệt , một đối tượng nên tránh gọi các phương thức của đối tượng thành viên được trả lại bằng một phương thức khác

Nếu bạn đang lo lắng về 3 được kết hợp chặt chẽ, sau đó loại bỏ các truy cập công cộng và thêm một phương pháp vào thể loại để thiết lập giá trị. Sau đó, hiệu suất Refactor và BigPerformance là thành viên riêng tư.

Answer 4

Một trong những câu yêu thích của tôi từ Martin Fowler:

Tôi muốn nó được gọi là Đề xuất thoảng hữu ích của Demeter

http://haacked.com/archive/2009/07/14/law-of-demeter-dot-counting.aspx

Answer 5

Nếu bạn luôn giữ testabillity của các lớp học của bạn trong tâm trí và sử dụng IoC, bạn sẽ nhận thấy bạn không phải lo lắng về LoD càng nhiều.

Nhìn vào nó theo cách này

Làm thế nào tôi sẽ kiểm tra Category? Tôi không muốn tự động tạo một Performance đang sử dụng hệ thống tệp chậm . Hãy vượt qua một số IPerformance tới số Category và thay thế việc triển khai thực tế bằng mẫu giả Performance.

Tôi sẽ kiểm tra Performance bằng cách nào? Tôi không muốn tự động hóa tạo một số BigPerformance tạo kết nối với cơ sở dữ liệu. Hãy vượt qua một số IBigPerformance tới số Performance và thay thế thực tế thực hiện bằng hình thức giả BigPerformance.
...
bạn rõ ràng nhận thấy mô hình

Mã của bạn sẽ là trong dòng

BigPerformance BigPerf = new BigPerformance(); 
BigPerf.Value := 1.0; 
Performance Perf = new Performance(BigPerformance); 
Category cat = new Category(Performance); 

(This would be retrieved from a factory.) 

Có vẻ (và trong shortrun lẽ là) như rất nhiều nhiều công việc hơn nhưng lợi ích sẽ trả hết trong thời gian dài bằng cách có thể kiểm tra các lớp học của bạn một cách cô lập.

Hãy xem Misco Hevery's blog để mở mắt về chủ đề này và các chủ đề khác.