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


26

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?


36
"Mã hóa xấu" bao trùm nó;)
Oded

12
Phụ thuộc. Nó có phải là một trình bao bọc cho một thư viện đăng nhập? Nếu có cơ hội, nó có thể được hoán đổi thì đây thực sự là một cách làm tốt ...
Rig

3
@lortabac: Vấn đề với "mã baklava" là nó nghe có vẻ hay và ngon, và do đó được mong muốn.
Thất vọngWithFormsDesigner

10
Lập trình viên này nói gì khi bạn thêm chúng tại sao họ lại thêm các phương thức này? Hiểu lý luận của họ nên làm cho việc giáo dục họ dễ dàng hơn.
Keith

3
Âm thanh giống như một mức độ gián tiếp , có thể tốt khi bạn muốn tránh khớp nối giữa hai lớp, như @Rig chỉ ra. Có lẽ đó chỉ là một lập trình viên bị viêm mô hình - chỉ đơn giản là thử một số mô hình để giải quyết vấn đề không có ở đó, vi phạm KISS.
Fuhrmanator

Câu trả lời:


54

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" :-)


9
Tôi đã luôn luôn sử dụng "Địa ngục gián tiếp".
Dan Neely

27

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.


1
"Vấn đề trách nhiệm duy nhất"? SRP? Có lẽ bạn có nghĩa là để viết Nguyên tắc trách nhiệm duy nhất? Chỉ cần kết nối hai ở đây. :)
zxcdw

8

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.



4

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ý) ở đó.


Vẫn là một thực tế tồi vì: 1) không thể thay đổi 2) nếu nó thay đổi, họ chỉ có thể xây dựng một lớp bao bọc có cùng tên và thay đổi nhập khẩu.
kevin cline

2
+1. Và đây là "Chú Bob" (Robert Martin) tranh luận về việc tập trung vào các phụ thuộc trong một số mô-đun hạn chế, thay vì phân tán chúng thông qua mã.
MarkJ

3

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.


3

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.


2

Đ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 đề.


2

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


1

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.


1

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.


0

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 đó ".


1
Dễ viết ban đầu không phải là một lý do tốt cho sự trùng lặp. Mã xấu có thể dễ dàng hơn để viết lần đầu tiên, nhưng điều đó không làm cho việc viết mã dễ dàng hơn trong thời gian dài. Anh chàng mới đến làm gì với chức năng trùng lặp? Anh ta gọi phương thức nào? Anh ta lãng phí thời gian tìm kiếm chúng và đọc chúng, chỉ để thấy chúng làm điều tương tự.
Kazark

Có thể mã này ban đầu có nghĩa là một nguyên mẫu mà sau đó được (ab) sử dụng làm gia số. Trong trường hợp đó, tối ưu hóa cho văn bản ban đầu sẽ có giá trị, tôi nghĩ vậy.
Bengt
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.