Nhà điều hành null có điều kiện mới của C # 6.0 có trái với Luật Demeter không?

Các Luật của Demeter nói những điều sau đây:

• 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.

C # 6.0 đã giới thiệu một toán tử mới gọi là toán tử có điều kiện null . IMHO, nó làm cho mã hóa dễ dàng hơn và cải thiện khả năng đọc. Nhưng nó cũng làm cho việc viết mã được ghép dễ dàng hơn, vì nó dễ dàng điều hướng qua các trường lớp hơn, đã kiểm tra tính vô hiệu (đại loại như var x = A?.B?.C?.D?.E?.F?).

Có đúng không khi tuyên bố rằng nhà điều hành mới này đi ngược lại Luật Demeter?

Có đúng không khi tuyên bố rằng nhà điều hành mới này đi ngược lại Luật Demeter?

Không ^*

^* Toán tử điều kiện null là một công cụ trong ngôn ngữ và khung .NET. Bất kỳ công cụ nào cũng có khả năng bị lạm dụng và sử dụng theo những cách có thể gây hại cho khả năng duy trì của một ứng dụng nhất định.

Nhưng thực tế là một công cụ có thể bị lạm dụng không nhất thiết có nghĩa là nó có bị lạm dụng, cũng không phải là công cụ vi phạm bất kỳ nguyên tắc cụ thể (s) có thể sẽ được tổ chức.

Luật Demeter và những người khác là hướng dẫn về cách bạn nên viết mã của mình. Nó nhắm đến con người, không phải công cụ. Vì vậy, thực tế là ngôn ngữ C # 6.0 có một công cụ mới bên trong nó không nhất thiết ảnh hưởng đến cách bạn nên viết và cấu trúc mã của mình.

Với bất kỳ công cụ mới nào, bạn cần đánh giá nó là ... nếu anh chàng người kết thúc việc duy trì mã của bạn sẽ trở thành một kẻ tâm thần bạo lực ... . Lưu ý một lần nữa, đây là hướng dẫn cho người viết mã chứ không phải về các công cụ đang được sử dụng.

Sắp xếp

Nếu bạn chỉ thực hiện một truy cập (a?.Foo ) thì nó tương đương với:

a == null ? null : a.Foo

mà hầu hết mọi người sẽ đồng ý không phải là vi phạm Luật Demeter. Tại thời điểm đó, nó chỉ là đường cú pháp để cải thiện khả năng đọc.

Bất cứ điều gì hơn thế, và nó có thể sẽ vi phạm Luật Demeter, và tính năng này có xu hướng thúc đẩy loại sử dụng đó. Tôi thậm chí sẽ nói rằng chỉ riêng cách sử dụng "tốt" ở trên là không đủ để đảm bảo loại thay đổi này đối với ngôn ngữ, vì vậy tôi hy vọng rằng nó được tạo ra để hỗ trợ việc sử dụng ít rõ ràng hơn.

Điều đó nói rằng, điều đáng ghi nhớ là Luật Demeter không phải là luật pháp, mà là một hướng dẫn. Rất nhiều mã vi phạm nó và hoạt động tốt. Đôi khi sự đơn giản của thiết kế hoặc mã có giá trị cao hơn rủi ro do vi phạm Luật Demeter.

Không. Hãy xem xét cả người vận hành, và việc sử dụng rất nhiều bạn có cho nó.

Tự nó .?Aphụ thuộc vào cùng một lượng kiến ​​thức của lớp, giá trị bên trái là và loại được trả về bởi phương thức .A != null, viz. Nó cần biết về Atài sản tồn tại và trả về một giá trị có thể so sánh với null.

Chúng tôi chỉ có thể lập luận rằng điều này vi phạm luật của Demeter nếu tài sản đánh máy làm. Chúng tôi thậm chí không bị buộc phải có Amột loại cụ thể (giá trị của nó có thể là một loại dẫn xuất). Các khớp nối ở đây là tối thiểu.

Bây giờ hãy xem xét var x = A?.B?.C?.D?.E?.F.

Điều đó có nghĩa là Aphải thuộc loại có thể là null hoặc có thể có một thuộc Btính, phải là loại có thể là null hoặc có một Ctài sản, và cứ như vậy cho đến khi loại Etài sản đó là một thứ gì đó có thể là null hoặc có thể có một Ftài sản.

Nói cách khác, chúng ta cần thực hiện điều này với một ngôn ngữ gõ tĩnh hoặc đã áp dụng một ràng buộc đối với các loại có thể được trả về nếu gõ bị lỏng. C # trong hầu hết các trường hợp sử dụng kiểu gõ tĩnh, vì vậy chúng tôi không thay đổi gì.

Nếu chúng ta có thì đoạn mã sau cũng sẽ vi phạm luật:

ExplicitType x;
var b = A.B;
if (b == null)
  x = null;
else
{
  var c = b.C;
  if (c == null)
    x = null;
  else
  {
    var d = c.D;
    if (d == null)
      x = null;
    else
    {
      var e = d.E;
      if (e == null)
        x = null;
      else
        x = e.F;
    }
  }
}

Mà chính xác là như nhau . Mã này đang sử dụng khớp nối của các yếu tố khác nhau cần "biết" về chuỗi khớp nối đầy đủ, nhưng nó sử dụng mã không vi phạm Luật Demeter để làm như vậy, với mỗi đơn vị có khớp nối được xác định rõ với tiếp theo.

Đối tượng có thể được tạo ra cho mục đích đóng gói các hành vi hoặc lưu giữ dữ liệu và các đối tượng có thể được tạo cho mục đích chia sẻ với mã bên ngoài hoặc được giữ riêng bởi người tạo.

Các đối tượng được tạo ra cho mục đích đóng gói hành vi (dù được chia sẻ hay không) hoặc để được chia sẻ với mã bên ngoài (cho dù chúng đóng gói hành vi hoặc dữ liệu) thường nên được truy cập qua giao diện bề mặt của chúng. Tuy nhiên, khi các đối tượng lưu trữ dữ liệu được tạo ra để sử dụng riêng cho người tạo ra chúng, các lý do Luật pháp thông thường để tránh truy cập "sâu" không được áp dụng. Nếu một phần của lớp lưu trữ hoặc thao tác dữ liệu trong đối tượng bị thay đổi theo cách yêu cầu điều chỉnh mã khác, có thể đảm bảo rằng tất cả các mã đó được cập nhật vì - như đã lưu ý ở trên - đối tượng được tạo cho việc sử dụng độc quyền của một lớp.

Trong khi tôi nghĩ rằng? Toán tử có lẽ đã được thiết kế tốt hơn, có đủ các tình huống trong đó các đối tượng sử dụng các cấu trúc dữ liệu lồng nhau mà toán tử có nhiều trường hợp sử dụng không vi phạm các nguyên tắc được thể hiện bởi Luật Demeter. Không nên coi thực tế là nó có thể được sử dụng để vi phạm LoD như là một đối số chống lại nhà điều hành, vì nó không tệ hơn "." điều hành trong vấn đề đó.