Чи є антипатерн для опису цього методу кодування? [зачинено]

У мене є база коду, де програміст, як правило, загортає речі в області, які не мають сенсу. Наприклад, враховуючи журнал помилок, який у нас ви можете увійти через

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

Він додав різні інші засоби для виконання точно такого ж завдання. EG

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

Який просто обертається і викликає перший метод. Це додає рівня складності без додаткової користі. Чи є антидіаграма, щоб описати це?

Називати якусь погану звичку кодування Антипатерн варто лише тоді, коли вона досить поширена.

Решту ми просто називаємо "кодом сміття" ...

Якби я запропонував назву саме цієї шкідливої ​​звички, це було б "Нав'язливий розлад абстракції" :-)

Ні, це не анти-модель, але я б порушив наступні питання.

Порушення принципу єдиної відповідальності

SRP каже, що у класу повинна бути одна причина для зміни. Додавання методу реєстратора означає, що клас також повинен змінитися, якщо слід змінити логіку журналу.

Порушення is-aвідносин

Базові класи не є набором інструментів, куди можна додати кілька зручних методів.

Це ефективно з'єднує всі успадковані класи з реалізаціями, які має базовий клас.

Порівняйте це зі складом.

Не те, що це робить його прийнятним, але це може бути просто незавершеним реконструкцією. Можливо, SomeClass.log () мав власну логіку, а спочатку був реалізований. І пізніше вони зрозуміли, що вони повинні використовувати ErrorLog.Log (). Тому замість того, щоб змінити 100 місць, де викликається SomeClass.Log (), вони просто делеговані на ErrorLog.Log (). Я особисто змінив би всі посилання на ErrorLog.Log () або, принаймні, прокоментував SomeClass.log (), щоб сказати, чому він делегує так, як це робиться.

Просто щось врахувати.

Термін «Код Лазаньї» мені спадає на думку, хоча, мабуть, він означає різні речі для різних людей . Моя інтерпретація завжди була "шаруватою заради шару".

Я не впевнений, щоб описати це як правопорушення до принципу єдиної відповідальності, тому що якщо відбудеться зміна підпису методу ErrorLog (метод, який викликається SomeClass), кожен код клієнта, який викликає цей метод, вийде з ладу.

Очевидно, існує спосіб використання успадкування (або створення класів, для яких потрібен журнал, реалізуючи інтерфейс журналу).

Або ми могли б сприймати це як "навчальний момент" :)

Ваш розробник може бути на півдорозі до гарної ідеї. Припустимо, ви хочете мати вимогу про те, щоб усі ваші бізнес-об'єкти мали можливість інтелектуального ведення журналу. Ви можете визначити:

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

Тепер внутрішньо для ваших об'єктів ви можете використовувати об'єкт ErrorLog для фактичного ведення журналу, тоді як код SomeClass додає до журналу повідомлення певного значення об'єкта. Потім можна додатково розширити API реєстрації журналів, щоб реалізувати функціонування журналів на основі файлів, db чи повідомлень, не торкаючись ваших бізнес-об’єктів.

Я не впевнений, що це автоматично зло.

Якщо ви телефонуєте SomeClass.Log, це, безумовно, є злом, але якщо журнал використовується тільки в межах SomeClass, він скорочує з'єднання, і я вважаю це прийнятним.

Це насправді досить поширене в певних стилях кодування, і основи лінії думки самі по собі не є антидіаграмою.

Це, ймовірно, результат того, що хтось кодує необхідність без знання ширшої бази коду: "Гаразд, цей код повинен ввести помилку, але ця функція не є основним призначенням коду. Тому мені потрібен метод / клас, який буде робити це для мене". Це хороший спосіб мислення; але, не знаючи, що існує помилка ErrorLog, вони створили SomeClass. Потім вони знайшли ErrorLog в якийсь пізній момент, і замість того, щоб замінити всі звичаї методу, який вони ввели, вони зробили свій метод викликом ErrorLog. Саме тут це стає проблемою.

Випадкова складність - це складність, яка виникає в комп'ютерних програмах або в процесі їх розробки, що не є важливим для вирішуваної проблеми. Хоча суттєва складність притаманна та неминуча, випадкова складність зумовлена ​​підходом, обраним для вирішення проблеми.

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

Це може бути зловживання / нерозуміння фасадної моделі . Я бачив подібні речі в кодовій базі, з якою працював. Розробники пройшли фазу, коли вони шаленіли від моделей дизайну, не розуміючи загальних принципів дизайну ОО.

Неправильне використання фасадного шаблону призводить до розмивання рівнів абстракції в шарах програми.

Це робить цей програміст - це загортання деякого коду, щоб він не мав прямої залежності від модуля реєстрації. Без більш конкретної інформації неможливо дати більш конкретний зразок. (Те, що ці обгортки не корисні, - це ваша думка, з якою неможливо погодитись або не погодитись без набагато більшої інформації.)

Моделі, під які це може потрапити, - це проксі , делегат , декоратор , композитний або деякі такі, що стосуються обгортання, приховування або розповсюдження викликів. Це може бути одна з таких речей у неповному стані розвитку.

Я міг би уявити, що це культурна різниця. Можливо, є вагомі причини для дублювання функціональності в цій конкретній кодовій базі. Я міг би уявити легкість написання як таку причину. Програміст Python в мені все ще сказав би це погано, оскільки " повинен бути один - і бажано лише один - очевидний спосіб зробити це ". Але деякі хлопці Perl можуть бути звикли до того, що " Є більше одного спосіб це зробити ".