Có một antipotype để mô tả phương pháp mã hóa này? [đóng cửa]

Tôi có một cơ sở mã nơi lập trình viên có xu hướng bọc mọi thứ ở những khu vực không có ý nghĩa. Ví dụ: được cung cấp một nhật ký Lỗi, chúng tôi có thể đăng nhập thông qua

ErrorLog.Log(ex, "friendly message");

Ông đã thêm nhiều phương tiện khác để hoàn thành chính xác nhiệm vụ. VÍ DỤ

SomeClass.Log(ex, "friendly message");

Mà chỉ đơn giản là quay lại và gọi phương thức đầu tiên. Điều này thêm mức độ phức tạp mà không có thêm lợi ích. Có một mô hình chống để mô tả điều này?

Chỉ đáng để gọi một số thói quen mã hóa xấu là Antipotype nếu nó phổ biến rộng rãi.

Phần còn lại chúng tôi chỉ gọi là "mã rác" ...

Nếu tôi đề xuất một tên cho thói quen xấu đặc biệt này, thì đó sẽ là "Rối loạn trừu tượng ám ảnh" :-)

Không, đó không phải là một mô hình chống nhưng tôi sẽ nêu ra các vấn đề sau.

Vi phạm nguyên tắc trách nhiệm duy nhất

SRP nói rằng một lớp nên có một lý do để thay đổi. Thêm một phương thức logger có nghĩa là lớp cũng phải thay đổi nếu logic ghi nhật ký nên được thay đổi.

Vi phạm một is-amối quan hệ

Các lớp cơ sở không phải là hộp công cụ nơi bạn có thể thêm một số phương thức tiện lợi.

Làm như vậy một cách hiệu quả tất cả các lớp kế thừa cho các triển khai mà lớp cơ sở có.

So sánh điều đó với thành phần.

Không phải điều này làm cho nó chấp nhận được nhưng đây chỉ có thể là một cấu trúc lại chưa hoàn thành. Có lẽ một sốClass.log () có logic riêng của nó đã được triển khai trước tiên. Và sau đó họ nhận ra rằng họ nên sử dụng ErrorLog.Log (). Vì vậy, thay vì thay đổi 100 vị trí được gọi là someClass.Log (), họ chỉ được ủy quyền cho ErrorLog.Log (). Cá nhân tôi sẽ thay đổi tất cả các tham chiếu thành ErrorLog.Log () hoặc ít nhất là nhận xét someClass.log () để nói lý do tại sao nó ủy thác theo cách nó làm.

Chỉ cần một cái gì đó để xem xét.

Thuật ngữ "Mã Lasagna" xuất hiện trong đầu tôi, mặc dù rõ ràng nó có nghĩa là những thứ khác nhau đối với những người khác nhau . Giải thích của tôi luôn luôn được "xếp lớp vì lợi ích của lớp".

Tôi không chắc chắn mô tả điều này là vi phạm nguyên tắc trách nhiệm duy nhất, bởi vì nếu có thay đổi đối với chữ ký phương thức ErrorLog (phương thức được gọi bởi someClass), mọi mã máy khách gọi phương thức này sẽ thất bại.

Rõ ràng có một cách để sử dụng tính kế thừa (hoặc tạo các lớp cần ghi nhật ký thực hiện giao diện ghi nhật ký) ở đó.

Hoặc chúng ta có thể xem đây là một "khoảnh khắc có thể dạy được" :)

Nhà phát triển của bạn có thể là một nửa cho một ý tưởng tốt. Giả sử bạn muốn có yêu cầu rằng tất cả các đối tượng kinh doanh của bạn có khả năng đăng nhập thông minh. Bạn có thể định nghĩa:

   public interface IBusinessObjectLogger
   {
       void Log(Exception ex, string logMessage)
   }

Bây giờ nội bộ cho các đối tượng của bạn, bạn có thể sử dụng đối tượng ErrorLog để thực hiện ghi nhật ký trong khi mã someClass thêm giá trị cụ thể của đối tượng vào thông điệp tường trình. Sau đó, bạn có thể mở rộng thêm API ghi nhật ký của mình để triển khai chức năng ghi nhật ký dựa trên tệp, dựa trên db hoặc thông báo mà không cần chạm vào các đối tượng kinh doanh của bạn.

Tôi không chắc điều này tự động là xấu xa.

Nếu bạn đang gọi someClass.Log thì chắc chắn là xấu nhưng nếu Log chỉ được sử dụng từ FORIN someClass thì nó sẽ cắt khớp nối và tôi sẽ gọi nó là chấp nhận được.

Điều này thực sự khá phổ biến trong các phong cách mã hóa nhất định và những điều cơ bản của dòng suy nghĩ không phải là một kiểu chống đối.

Rất có thể đó là kết quả của việc ai đó mã hóa bởi sự cần thiết mà không có kiến ​​thức về cơ sở mã rộng hơn: "OK, mã này cần ghi lại lỗi, nhưng chức năng đó không phải là mục đích chính của mã. Vì vậy, tôi cần một phương thức / lớp sẽ làm điều đó. cho tôi". Đó là một cách suy nghĩ tốt; nhưng, không biết ErrorLog tồn tại, họ đã tạo ra một sốClass. Sau đó, họ đã tìm thấy ErrorLog tại một số điểm sau đó và thay vì sử dụng tất cả các cách sử dụng phương thức mà họ đã đưa vào, họ đã thực hiện phương thức gọi ErrorLog. Đó là nơi điều này trở thành một vấn đề.

Sự phức tạp ngẫu nhiên là sự phức tạp nảy sinh trong các chương trình máy tính hoặc quá trình phát triển của chúng, điều không cần thiết cho vấn đề cần giải quyết. Mặc dù sự phức tạp thiết yếu là cố hữu và không thể tránh khỏi, sự phức tạp tình cờ được gây ra bởi phương pháp được lựa chọn để giải quyết vấn đề.

http://en.wikipedia.org/wiki/Accidental_complexity

Nó có thể là một sự lạm dụng / hiểu lầm về Mẫu mặt tiền . Tôi đã thấy những điều tương tự trong một cơ sở mã mà tôi đã làm việc với. Các nhà phát triển đã trải qua một giai đoạn khi họ phát cuồng với các mẫu thiết kế mà không hiểu các nguyên tắc bao quát của thiết kế OO.

Việc sử dụng sai mẫu Mặt tiền dẫn đến làm mờ các mức độ trừu tượng trên các lớp của ứng dụng.

Những gì lập trình viên này đang làm là gói một số mã, để nó không có sự phụ thuộc trực tiếp vào mô đun ghi nhật ký. Không có thông tin cụ thể hơn, không thể đưa ra một mô hình cụ thể hơn. (Việc các trình bao bọc này không hữu ích là ý kiến ​​của bạn không thể đồng ý hoặc không đồng ý nếu không có nhiều thông tin hơn.)

Các mẫu mà điều này có thể thuộc về Proxy , Delegate , Decorator , Composite hoặc một số thứ liên quan đến việc gói, ẩn hoặc phân phối các cuộc gọi. Nó có thể là một trong những điều như vậy trong trạng thái phát triển không hoàn chỉnh.

Tôi có thể tưởng tượng nó là sự khác biệt văn hóa. Có lẽ có một lý do chính đáng để có chức năng trùng lặp trong cơ sở mã cụ thể này. Tôi có thể dễ dàng hình ảnh bằng văn bản là một lý do như vậy. Lập trình viên Python trong tôi vẫn nói điều đó thật tệ, vì " Nên có một - và tốt nhất là chỉ có một cách rõ ràng để làm điều đó. ", Nhưng một số kẻ Perl có thể quen với thực tế rằng " Có nhiều hơn một cách để làm điều đó ".