Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
опишите статичный метод, если контекст this не нужен, и скрывайте реализацию как душе угодно. а создавать "никому не нужные" обьекты - это все равно маразм, и аукается и на памяти (замусоривание), и на производительности
> return new LoaderGroup().loadBytes(bytes, parserOptions);
вот в данном случае - создается обьект, который загружает данные, при этом данные возвращаются, а загрузчик безвозвратно отправляется в мусорный контейнер
Но вот то что возвращает LoaderGroup а не интерфейс... Впрочем придирки это все, вполне нормальный код, даже супер прогер и не то в реальном рабочем процессе переделок напишет.
Если задача меняется каждые несколько дней, если планируется расширение...
Я такие конструкции часто пишу когда проектирую структуру, под рефракторинг. Потом они благополучно умирают, когда добавляется функционал.
Грамотно с точки конкретного момента, но не факт что в уме автора нету знаний о том как это все будет расширятся.
Эмм, вы когда нибудь по двадцать часов в день несколько дней подряд кодили? Я думаю так и рождается неплохая часть эпика выложенного сюда.
Этот код - вполне грамотный.
Ну, какбэ... не трудно было дать другое имя, createAndLoadBytes, например. Или хотя бы с большой буквы написать. FD вообще отказался переходить в правильную функцию по F4. А с точки зрения языка, который не поддерживает перегрузку функций, возможность называть одинаково потенциально совершенно независимые функции контринтуитивна и "needlessly confusing".
Нет, не нужно было называть другим именем. Правильно называть таким именем, которое точно отражает назначение.
Я вижу говнокод в том, что можно было сделать так:
public const loadBytes:Function = LoaderGroup.loadBytes;
Т.как вторая функция все равно ничего нового к первой не добавила. Недостаток - не известен тип аргументов функции. Я в таком случае делал бы:
public const loadBytes:Function /* ByteArray->Null<ParserOptions>->LoaderGroup */ = LoaderGroup.loadBytes;
Но это зависит от того, знакомы ли разработчики с HaXe / согласны ли они мирится с тем, что код будет не до конца проверятся компилятором и т.п.
Но, вообще, если чесно, я не вижу надобности во второй функции - зачем, если она ничего принципиально нового не делает?
Так я и говорю, что не надо было так делать 🙂 Функция-то все равно одна, нужно было ее изначально статической делать. Смысл писать функцию, которая ничего кроме вызова другой функции не делает от меня ускользает.
О, смысл есть. Пример — как раз парсер. В процессе рабора может использоваться множество вспомогательных функций и несколько переменных, описывающих состояние парсера. Можно все эти переменные передавать в каждую вспомогательную функцию, а можно завести класс и инкапсулировать туда данные и методы. После того, как парсер отработал, объект не нужен. По идее вторая функция (как и все вспомогательные методы, конструктор и данные) могла бы быть приватной. Но иногда полезно явно создать парсер, настроить его и иметь доступ к состоянию на случай ошибки.
Автор говнокода совместил Factory c Утилитным методом.. Вполне возможно сначала был статический метод а затем когда он показал несостоятельность - втихаря заменил на метод инстанса. Кошернее было бы сделать новый класс - но наверное мало времни было )
why?
/ftfy/
Каюсь - сама так иногда пишу
вот в данном случае - создается обьект, который загружает данные, при этом данные возвращаются, а загрузчик безвозвратно отправляется в мусорный контейнер
Я такие конструкции часто пишу когда проектирую структуру, под рефракторинг. Потом они благополучно умирают, когда добавляется функционал.
Грамотно с точки конкретного момента, но не факт что в уме автора нету знаний о том как это все будет расширятся.
Этот код - вполне грамотный.
хватит приставать к женщинам :-Р
Я вижу говнокод в том, что можно было сделать так:
Т.как вторая функция все равно ничего нового к первой не добавила. Недостаток - не известен тип аргументов функции. Я в таком случае делал бы:
Но это зависит от того, знакомы ли разработчики с HaXe / согласны ли они мирится с тем, что код будет не до конца проверятся компилятором и т.п.
Но, вообще, если чесно, я не вижу надобности во второй функции - зачем, если она ничего принципиально нового не делает?
Имена, согласен, лучше бы разные использовать.