Чи подібний код - «аварія поїзда» (з порушенням Закону про Деметер)?

Переглядаючи якийсь код, який я написав, я натрапив на наступну конструкцію, яка змусила мене задуматися. На перший погляд, це здається досить чистим. Так, у фактичному коді getLocation()метод має трохи більш конкретну назву, яка краще описує, яке саме місце він отримує.

service.setLocation(this.configuration.getLocation().toString());

У цьому випадку serviceє змінною екземпляра відомого типу, оголошеною в межах методу. this.configurationпоходить від передачі до конструктора класів і є екземпляром класу, що реалізує певний інтерфейс (який мандатує публічний getLocation()метод). Отже, this.configuration.getLocation()відомий зворотний тип виразу ; конкретно в цьому випадку він є java.net.URL, тоді як service.setLocation()хоче a String. Оскільки два типи String і URL не є безпосередньо сумісними, для встановлення квадратного кілка в круглий отвір потрібне певне перетворення.

Однак , в Відповідно до Закону про Деметрі , як цитується в чистому кодексі , метод F в класі C повинен викликати тільки методи на C , об'єкти , створені або передаються в якості аргументів е , і об'єкти проведені в змінних екземпляра C . Все, що є поза цим (остаточне toString()в моєму конкретному випадку вище, якщо ви не вважаєте тимчасовим об'єктом, створеним в результаті виклику методу, і в цьому випадку весь Закон здається суперечливим) заборонено.

Чи є обґрунтовані міркування, чому такий виклик, як вище, з урахуванням перелічених обмежень, слід відмовити чи навіть заборонити? Або я просто надмірно нудотний?

Якби я реалізувати метод , URLToString()який просто викликає toString()на URLоб'єкт (наприклад, що повертається getLocation()) , переданого їй у якості параметра, і повертає результат, я міг би обернути getLocation()виклик в ній для досягнення точно такий же результат; Ефективно, я просто переміщу конверсію на крок назовні. Це зробило б це якось прийнятним? (Мені здається , інтуїтивно зрозуміло, що це не має жодних змін і в іншому випадку, оскільки все, що робиться, - це трохи перемістити речі. Однак, йдучи за цитатою літери Закону про Деметер, це було б прийнятно, оскільки я Тоді він буде працювати безпосередньо над параметром функції.)

Чи має щось значення, якби мова йшла про щось дещо екзотичніше, ніж запрошення toString()стандартного типу?

Відповідаючи, майте на увазі, що зміна поведінки або API типу, яким є serviceзмінна, не є практичним. Також, для аргументації, скажімо, що зміна типу повернення getLocation()також недоцільно.

Проблема тут - підпис setLocation. Це строго набрано .

Для уточнення: навіщо це очікувати String? A Stringявляє собою будь-який вид текстових даних . Потенційно це може бути будь-що, крім дійсного місця.

Насправді це ставить питання: що таке місцезнаходження? Як мені знати, не дивлячись на ваш код? Якби це було, URLя б знав набагато більше про те, що очікує цей метод.
Можливо, було б більше сенсу, щоб це був спеціальний клас Location. Гаразд, я б не знав спочатку, що це таке, але в якийсь момент (напевно, перед тим, як написати, this.configuration.getLocation()мені знадобиться хвилина, щоб зрозуміти, що це за метод повертається).
Зрозуміло, в обох випадках мені потрібно шукати десь інше, щоб зрозуміти, що очікується. Однак в останньому випадку, якщо я розумію, що Locationтаке, я можу використовувати ваш API, в першому випадку, якщо я розумію, що Stringтаке (що можна очікувати), я все ще не знаю, що очікує ваш API.

За малоймовірного сценарію, що місцеположення - це будь-який тип текстових даних, я б реінтерпретував це у будь-який тип даних, що має текстове представлення . Зважаючи на той факт, що у Objectвас є toStringметод, ви можете піти з цим, хоча це вимагає досить стрибка віри від клієнтів вашого коду.

Також слід врахувати, що це мова про Яву, про яку ви говорите, яка має дуже мало функцій. Ось що змушує вас насправді зателефонувати toStringв кінці.
Якщо ви візьмете, наприклад, C #, який також є статично набраним, ви насправді зможете опустити цей виклик, визначивши поведінку для неявного складу .
У динамічно набраних мовах, таких як Objective-C, конвертація теж не потрібна, оскільки поки значення веде себе як рядок, всі радіють.

Можна стверджувати, що останній дзвінок - toStringце менше дзвінка, ніж насправді просто шум, породжений вимогою Java на явність. Ви називаєте метод, який має будь-який об’єкт Java, тому ви фактично не кодуєте ніяких знань про "віддалену одиницю" і тим самим не порушуєте Принцип найменших знань. Немає способу, незалежно від того, що getLocationповертається, що у нього немає toStringметоду.

Але, будь ласка, не використовуйте рядки, якщо вони справді не є найбільш природним вибором (або якщо ви не використовуєте мову, яка навіть не має перерахунків ... там).

Закон Деметра - це орієнтир дизайну, а не закон, якого слід дотримуватися релігійно.

Якщо ви вважаєте, що ваші заняття достатньо відокремлені, ніж немає нічого поганого в рядку, this.configuration.getLocation()особливо якщо, як ви кажете, міняти інші частини API не доцільно.

Я майже впевнений, що клієнт буде абсолютно щасливий, навіть якщо ви складете Закон Деметера на шматки, якщо ви доставите все, що він хоче, і вчасно. Що не є приводом для створення поганого програмного забезпечення, але нагадування бути прагматичним при розробці програмного забезпечення.

Єдине, що я можу подумати, щоб не писати код, як це, це те, що якщо this.configuration.getLocation()повертає null? Це залежить від вашого оточуючого коду та цільової аудиторії, яка використовує цей код. Але як каже Марко - закон Деметра - це головне правило - добре слідувати, але не ламайте спину, роблячи це без потреби.

Якщо суворо дотримуватися Закону Деметра, це означає, що ви повинні реалізувати такий метод в об'єкт конфігурації, як:

function getLocationAsString() {
  return getLocation().toString();
}

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