LINUX.ORG.RU

Создание микроклассов и антипаттерн полтергейст

 ,


0

2

В книге «Clean Code: A Handbook of Agile Software Craftsmanship» от Robert C. Martin есть такой пример плохого, неочевидного кода:

private void printGuessStatistics(char candidate, int count) {
    String number;
    String verb;
    String pluralModifier;
    if (count == 0) {
      number = "no";
      verb = "are";
      pluralModifier = "s";
    } else if (count == 1) {
      number = "1";
      verb = "is";
      pluralModifier = "";
    } else {
      number = Integer.toString(count);
      verb = "are";
      pluralModifier = "s";
    }
    String guessMessage = String.format(
      "There %s %s %s%s", verb, number, candidate, pluralModifier
    );
    print(guessMessage);
  }

Автором предлагается переделать этот код в отдельный класс:

public class GuessStatisticsMessage {
  private String number;
  private String verb;
  private String pluralModifier;
  public String make(char candidate, int count) {
    createPluralDependentMessageParts(count);
    return String.format(
      "There %s %s %s%s", 
       verb, number, candidate, pluralModifier );
  }
  private void createPluralDependentMessageParts(int count) {
    if (count == 0) {
      thereAreNoLetters();
    } else if (count == 1) {
      thereIsOneLetter();
    } else {
      thereAreManyLetters(count);
    }
  }
  private void thereAreManyLetters(int count) {
    number = Integer.toString(count);
    verb = "are";
    pluralModifier = "s";
  }
  private void thereIsOneLetter() {
    number = "1";
    verb = "is";
    pluralModifier = "";
  }
  private void thereAreNoLetters() {
    number = "no";
    verb = "are";
    pluralModifier = "s";
  }
}

Как вы считаете насколько это оправдано на самом деле? Ведь налицо использование антипаттерна полтергейста, когда создается микрокласс с несколькими простейшими функциями.



Последнее исправление: demensdeum (всего исправлений: 1)

Я за бан.

anonymous
()
Ответ на: комментарий от tailgunner

В разбиении больших сущностей на более мелкие, с которыми легче работать. А сам пример хрень та ещё, да

Deleted
()
Ответ на: комментарий от Deleted

В разбиении больших сущностей на более мелкие, с которыми легче работать.

А. Ну это, конечно, очень здравый подход. Только надо помнить, что сложность определяется не только величиной сущностей, но и их количеством.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

надо помнить

Разумеется, баланс везде нужен

Deleted
()

Stop "Going Agile"! (C)

Развлекайтесь по полной -

https://habr.com/post/153225/

Собственно, все эти заумные паттерны - реально «корпоративная шиза».

И если на собеседовании спрашивают не то, что действительно практически делали раньше, а всякую теоретическую муть - смело встаньте и уйдите с такого интервью.

У меня есть коллега, которого в [компания известна своим снобизмом и «enterpriZe slaves»(TM), не буду называть] спросили про _структуру аки GoF_(!!!) паттернов GRASP.

Внимание! Вообще-то шаблоны GRASP «не имеют выраженной структуры, четкой области применения и конкретной решаемой проблемы, а лишь представляют собой обобщенные подходы/рекомендации/принципы, используемые при проектировании дизайна системы.»(С) Капитан Очевидность.

---

ЗЫ. Откуда взялись эти нелепые конструкции - у меня есть предположение. Если высокая текучка в компании, то манагерочки думают, что в такой «теоретически верный» код ньюкамер «въедет» быстрее.

Bioreactor ★★★★★
()
Последнее исправление: Bioreactor (всего исправлений: 2)

Строки и инты - это очень низкоуровневые вещи. Везде нужно использовать тип с явным набором операций над ним. Например, строки можно конкатенировать, имена людей нельзя конкатенировать нет в этом смысла.

Айдишки, пароли, имена файлов, номера телефонов, URL'ы, много всего - все что можно статически осмыслить нужно статически осмыслить и обернуть в типы.

vlad9486
()

Для борьбы с квадратно-гнездовым разрастанием-измельчением чего-либо давно придумали fine-grained decomposition. Т.е. если что-то занимает пять экранов — возможно лучше его разбить, просто чтоб сделать обозримым. Если оно помещается в экран — нафига разбрасывать код по классам, которые больше нигде не используются? В каждом конкретном случае твои друзья — чувство меры и «проверка на маразм». А то многие «экстрактируют» что-либо «потому что могут», а не потому что нужно. Конкретно этот пример — вообще надуманный, хотя эту книшко уже многие карго-культисты (как раз без чувства меры, с готовыми знаниями «потому что в книжке вот так») используют как «священную» :)

slackwarrior ★★★★★
()
Ответ на: комментарий от UVV

ни в коем случае их нельзя воспринимать за догму. Я пока у Uncle Bob не увидел подобной оговорки.

У секты «Идеального кода» есть прямо противоположная — это именно догма, потому что границы применимости «добрых советов» даются редко вместе с советами :) Чтоб до них дошло что что-то не так — их довольно легко тралить доведением примеров до абсурда и особенно — выхлопами наиболее последовательных последователей советов — т.е. тех самых падаванов, которые выдают нечто изумляющее, точно следуя рекомендациям. Экстрактируют методы, которые не используются, ложат болт на проектные гайдлайны, серют «паттернами», которые в том месте не уперлись, и т.д.

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от slackwarrior

Дошёл до нужных строк в книге:

We will present these opinions as absolutes, and we will not apologize for our stridence. To us, at this point in our careers, they are absolutes.

Ну т.е. главное не упустить то жирное, что я выделил, а то все воспримут как должное. Хотя его другая книга мне доставила, Clean Coder которая.

UVV ★★★★★
()
Ответ на: комментарий от slackwarrior

Сильно быстро написал. Я сейчас этот абзац дальше читаю и он сравнивает программирование с разными стилями единоборств. Ну типа учишься у одного мастера одному стилю. Потом можешь вырасти и расширить свои горизонты и учиться у другого мастера, может быть обзразовать свою школу и т.п.. В общем аналогия корректная.

UVV ★★★★★
()
Ответ на: комментарий от UVV

Все эти поэтические сравнения конешно «осне блаародные», но искажают суть и уводят в сторону, льстя чьему-то самолюбию (всяких там «ниндзь» и прочих «самураев» чего-то), только граждан без ЧЮ или там не умеющих в метафоры такому учить — только портить :) Меня часто изумляли «проффесионалы»(ТМ) находящие аналогии между производством ПО и СТО или автозаводом. Когда им приводил в ответ нормировку типовых и никогда не меняющихся(!) операций на СТО — делали большие глаза и переводили тему на космические корабли которые бороздят. Ну и банально «молоток изменяющийся в руке» — это боек летящий «проффесионалу» условного «аджайла» в умное литсо. Любая эта идеология «чистоты» и «красоты» конечно прельстива и любовна в окружении пасущихся как попало котовпадаванов-кодерков, но ни одна из них не работает без осмысленного применения. А для осмысления надо перестать смотреть в рот всяким гуру и находить «противоположные общие места» модным в этом сезоне серебряным пулям.

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.