Lắp ráp các thuộc tính đa hướng rộng. Họ có ác không?

Question

Tôi đang làm việc trên một dự án mà chúng tôi có một số thuộc tính trong AssemblyInfo.cs, đang được phát đa hướng cho các phương thức của một lớp cụ thể.

[assembly: Repeatable(
AspectPriority = 2, 
AttributeTargetAssemblies = "MyNamespace", 
AttributeTargetTypes = "MyNamespace.MyClass", 
AttributeTargetMemberAttributes = MulticastAttributes.Public, 
AttributeTargetMembers = "*Impl", Prefix = "Cls")] 

Những gì tôi không thích về điều này, là nó đặt một miếng logic vào AssemblyInfo (Thông tin, tâm trí bạn!), Mà cho người mới bắt đầu không được chứa bất kỳ logic nào cả. Phần tồi tệ nhất của nó, đó là MyClass.cs thực sự không có thuộc tính ở bất kỳ đâu trong tệp, và hoàn toàn không rõ ràng rằng các phương thức của lớp này có thể có chúng. Theo quan điểm của tôi, nó làm tổn hại đến khả năng đọc của mã (không kể đến việc sử dụng quá mức PostSharp có thể làm cho việc gỡ rối một cơn ác mộng). Đặc biệt khi bạn có nhiều thuộc tính multicast.

Phương pháp hay nhất ở đây là gì? Có ai ngoài kia đang sử dụng các thuộc tính PostSharp như thế này không?

Answer 1

Để tôi trả lời đầu tiên cho Max: thực sự, các khía cạnh không phải là thay thế thành các mẫu OOP tốt. Chúng là một phần bổ sung . Bất kỳ thiết kế AOP tốt nào đều bắt đầu với thiết kế OOP tốt. Nhưng các mẫu OOP đôi khi buộc bạn phải viết rất nhiều mã bằng tay. Đối với những trường hợp này, các khía cạnh có thể được sử dụng để tự động tự động triển khai mẫu OOP, không để thay thế chúng.

Khi bạn sử dụng AOP một cách thông minh, giải pháp của bạn có thể dễ hiểu hơn (mã doanh nghiệp không được trộn lẫn với mã bảo trì), để kiểm tra (bạn có thể kiểm tra khía cạnh độc lập với mã doanh nghiệp, tức là bạn không phải kiểm tra bất kỳ phương pháp kinh doanh nào theo đúng cách), thay đổi (bạn chỉ cần thay đổi khía cạnh khi bạn muốn thay đổi mẫu, thay vì thay đổi mọi lần triển khai mẫu).Bây giờ, nếu bạn lạm dụng từ AOP, nếu bạn sử dụng nó như một công cụ hack, nếu bạn không nghĩ về các mẫu OOP trước đó, thì bạn sẽ nhận được nhiều chi phí hơn lợi ích từ AOP. Như bất kỳ công cụ sắc nét nào, AOP nên được sử dụng một cách thông minh.

Quay lại câu hỏi ban đầu.

Ai bảo bạn nên đặt các khía cạnh trong AssemblyInfo.cs? Bạn có thể tạo một tệp mới có tên GlobalAspects.cs và đặt tất cả các khía cạnh cấp độ lắp ráp ở đó. Bạn nói đúng rằng AssemblyInfo.cs chỉ nên dùng cho siêu dữ liệu ở mức lắp ráp.

Nhưng cũng giống như bạn, tôi không thích các khía cạnh cấp độ lắp ráp. Tôi nghĩ rằng cần phải tránh. Vấn đề chính với các khía cạnh cấp độ tinh vi là họ dựa vào các quy ước đặt tên, và điều này là điều ác. (Cái ác này được gọi là sự mong manh của pointcut trong cộng đồng AOSD học thuật.) Thật vậy, khi bạn đổi tên một lớp hoặc không gian tên, bạn thay đổi tập hợp các phương thức áp dụng và điều này có thể nhanh chóng trở thành cơn ác mộng. Đó là lý do tại sao tôi không bao giờ sử dụng các khía cạnh dựa trên quy ước đặt tên cho bản thân mình.

Điều gì về khả năng đọc mã? Ở mức độ lớn, tôi nghĩ rằng mã có thể đọc được là mã ngắn. Nếu tôi có một phương thức kinh doanh được gọi là CreateProduct, tôi có thể chỉ muốn xem mã tạo sản phẩm. Hầu hết thời gian, tôi không quan tâm đến mã xử lý giao dịch, ngoại lệ hoặc truy tìm. Đó là đủ nếu tôi biết rằng một số khía cạnh xử lý điều đó đối với tôi.

Và làm sao tôi biết? Với PostSharp, bạn có phần mở rộng Visual Studio. Với AspectJ, bạn có trình cắm thêm AspectJ cho Eclipse (AJDT). Chúng hiển thị cho bạn, bên trong IDE, các khía cạnh nào được áp dụng cho mã mà bạn hiện đang thấy. Và nếu bạn thực sự muốn xem chi tiết (nhưng bạn hiếm khi thực sự muốn), bạn có thể sử dụng trình gỡ rối để bước vào các khía cạnh hoặc sử dụng Trình phản xạ để xem mã được sản xuất.

Tóm tắt:

1. thiết kế AOP tốt luôn luôn bắt đầu với một thiết kế OOP tốt.
2. Tránh dựa vào các quy ước đặt tên để áp dụng các khía cạnh.
3. Sử dụng phần mở rộng PostSharp cho Visual Studio hoặc AJDT để trực quan hóa các khía cạnh trong mã của bạn.

Answer 2

Tôi chắc chắn đây sẽ là một câu trả lời không được ưa chuộng nhưng có lẽ tôi có thể nhận được đẳng áp huy hiệu của tôi ...

bản năng của bạn là chính xác. Đưa logic vào siêu dữ liệu của bất kỳ loại nào là một tội lỗi kinh khủng, khủng khiếp mà một trong những người đốt cháy vĩnh viễn trong địa ngục không thể duy trì được.

Tôi có nghĩa là không thiếu tôn trọng điều này mặc dù tôi chắc chắn nó sẽ được diễn giải khác.

Cách thực hành tốt nhất là không sử dụng các công cụ "lập trình có khía cạnh có khía cạnh", là những cái nạng cho phép thực hành thiết kế và thử nghiệm kém hiệu quả. Thay vào đó, hãy nhìn vào thiết kế của bạn và tự hỏi mình "tại sao".

Tại sao tôi cảm thấy cần phải sử dụng công cụ này? Vấn đề gì về thiết kế là tôi đang cố giải quyết?

Một khi bạn đã nắm vững vấn đề, đi nhặt Design Patterns Giải thích (Shalloway & Trott) hoặc Head First Design Patterns (Freeman, Robson, Bates, & Sierra).

Cuối cùng, giải pháp hướng mẫu sẽ dễ hiểu hơn, dễ kiểm tra hơn và dễ thay đổi hơn. Chi phí bổ sung duy nhất sẽ là phí duy nhất để làm chủ các mẫu thiết kế thay cho phí định kỳ khi cố gắng tìm ra tất cả các khía cạnh này, cách chúng khớp với nhau và cách chúng ảnh hưởng lẫn nhau mỗi khi bạn thực hiện thay đổi.