Секретный антишаблон квитирования
Вы можете взять каждый символ в строке для цикла for и сделать его заглавным, а затем добавить префикс и строку после исправления
var array=[];
const wave = (str) => {
if(typeof str === 'string' && str === str.toLowerCase()){
for (let index = 0; index < str.length; index++) {
if (str[index] === ' ') continue;
waveChar=str.charAt(index).toUpperCase();
preStr=str.substring(0,index);
postStr=str.substring(index,str.length-1);
array.push(preStr+waveChar+postStr);
}
}else{
alert(`${str} is either not a string or not lowercase`);
}
}
wave("hello");
console.log(array);4 ответа
Да, это анти-шаблон: Последовательное соединение .
Я бы реорганизовал в Опции - передал на завод, и Результаты , возвращенные методом analyseText () .
- Я ожидал бы, что AnalyzerFactory получит необходимые параметры и выполнит саму конструкцию; в противном случае, что именно он делает?
- Не уверен, что у него есть имя, но похоже, что оно должно:)
- Да, иногда удобно (и правильный уровень абстракции) иметь сеттеры в вашем интерфейсе. и ожидайте, что классы позвонят им. Я бы предположил, что для этого требуется обширная документация по этому факту.
- Не совсем, нет. Предпочтение неизменности - это, безусловно, хорошая вещь, и дизайн на основе сеттеров / bean-компонентов иногда может быть и «правильным» выбором, но ваш приведенный пример заходит слишком далеко.
Я не вижу здесь ничего плохого. setText () готовит сцену; после этого у вас есть один или несколько вызовов getOccurances () . Поскольку setText () очень дорогой, я не могу придумать другого способа сделать это.
getOccurances (text, query) исправит «секретное рукопожатие» с огромной производительностью Стоимость. Вы можете попытаться кэшировать текст в getOccurances () и обновлять свои внутренние кэши только при изменении текста, но это все больше и больше напоминает жертву некоему принципу ОО. Если правило не имеет смысла, не применяйте его. У разработчиков программного обеспечения есть разум по какой-то причине.
Я не уверен, является ли это описанным анти-паттерном, но я полностью согласен, что это плохо разработанный интерфейс. Это оставляет слишком много возможностей для ошибок и нарушает, по крайней мере, один ключевой принцип: сделать ваш API трудным для неправильного использования.
Помимо неправильного использования, этот API также может привести к трудным для отладки ошибкам, если несколько потоков используют один и тот же экземпляр.
Джошуа Блох на самом деле имеет отличную презентацию (36м16 и 40м30) по разработке API, и он рассматривает это как одну из характеристик плохо спроектированного API.