Хороший друг попросил у меня цитату сегодня, и я решил поделиться ею с вами. Рассмотрим этот фрагмент кода:
|
01
02
03
04
05
06
07
08
09
10
11
12
|
if (isThisAPremiumProductByIdInTheCatalogue(productId, products)) { // do something}..private static boolean isThisAPremiumProductByIdInTheCatalogue(String id, Map<String, String> products) { return products.get(id).equals(PREMIUM_PRODUCT);} |
Вопрос, который мне задали, заключался в том, был ли приведенный выше код лучше использовать метод самоописания, или следует использовать рефакторинг встроенного метода , как описано в статье «Рефакторинг Гуру» и как его разработал Мартин Фаулер . Как интересно, что первый сайт использует тот же пример, что и последний … где последний из первоисточника.
Во всяком случае, это интересная дилемма. Следующий код лучше?
|
1
2
3
|
if (products.get(id).equals(PREMIUM_PRODUCT)) { // do something} |
Вторая версия определенно более краткая. Первая версия, казалось, была супом слова и оператора…
Однако, если бы было несколько мест, где нужна эта логика, я бы хотел метод. Я также хотел бы метод, который не говорил бы так много. Как насчет этого?
|
1
2
3
|
private static boolean isPremium(String id, Map<String, String> products) { return products.get(id).equals(PREMIUM_PRODUCT);} |
И вы могли бы оставить это там …
Подобные вопросы могут закончиться чем-то вроде того, какую форму нам легче всего читать прямо сейчас? Как правило, вы хотите что-то, о чем не нужно слишком много думать и которое уравновешивает краткость с объяснением.
Но что происходит?
Старый трюк технического лидера — ответить на поставленный вопрос, а затем отступить назад и сказать что-то вроде: «Что здесь происходит, хотя?».
В приведенном выше коде есть эта карта, просто лежащая вокруг Чтобы понять это, нам нужна функция, чтобы решать вещи. Это случай пропущенного типа? Есть ли анемичная объектная модель, которая слишком анемична?
Должны ли мы сделать сервис для предоставления из данных некоторых полезных фактов?
Анемичная модель против данных о свободном
Дни умных объектов, как правило, прошли. Мы понимаем, что если мы добавим слишком много поведения к модельным объектам, они будут слишком связаны с неправильными вещами. Например, объект модели не должен знать, как себя спасти, потому что это плохо кончается. Точно так же, если у вас есть объект модели и некоторые функции программного обеспечения имеют предпочтительный способ его рендеринга, но некоторые другие функции программного обеспечения имеют другой — например, различие между форматом на экране и форматом на диске, модель, вероятно, не несет ответственности за реализацию преобразований в эти форматы.
Самое простое решение этого — иметь очень легкую объектную модель с геттерами и сеттерами и другими реальными основами, а затем иметь сервисы для преобразования этой объектной модели в другие вещи или получения данных из нее.
Я склонен считать, что такие вещи, как формат JSON, являются родными для объектной модели, которая была воплощена в жизнь для представления данных JSON.
Как правило, очевидно, что объект делает слишком много, если ему известно о нескольких внешних технологиях, которые заботятся о его представлении. Тем не менее, объекты модели, которые аннотированы для двух эквивалентных способов визуализации этой точной модели в JSON, могут быть в порядке…
И весь смысл обсуждения анемичной объектной модели состоит в том, чтобы напомнить вам, что Map не является объектной моделью. У нас есть данные на свободе .
Данные о свободе
Если у вас есть кое-что в памяти в базовых классах коллекций, и вам нужно создать алгоритмы общего назначения для извлечения этих данных, похоже, у вас может отсутствовать объект модели.
|
01
02
03
04
05
06
07
08
09
10
|
public class ProductCatalogue { private static final String PREMIUM = "premium-o"; private Map<String, String> products; ... public boolean isPremium(String productId) { return PREMIUM.equals(products.get(productId)); } } |
Как указывалось выше, одним из соображений является то, является ли это обозначение премии внешним мнением или внутренним аспектом модельного объекта. Похоже, что в этом случае это внутреннее объяснение того, как эта модель объясняет свое собственное внутреннее представление.
В итоге
Мы должны рефакторинг в основном для ясности. Вот почему книга рефакторинга имеет противоположности. Для каждой встроенной функции вы также можете использовать функцию извлечения .
Тем не менее, всегда смотрите на естественное разделение проблем и следите за данными на свободе!
|
Смотрите оригинальную статью здесь: Где поставить реализацию Мнения, высказанные участниками Java Code Geeks, являются их собственными. |