kkolyan
> 1. очень небольшие проекты. предел индивидуален - я не парюсь только если
> проект условно меньше 1000 строк.
>2. проекты-прототипы. могут быть немаленькими, но для них поддержка в принципе не >рассматривается - это write-only код. надо писать чем быстрее тем лучше в соответствии с задачами >прототипа. Если вы не набили руку кодить без статиков, то здесь их применять вполне нормально.
Не согласен, на мой взгляд это не тот критерий которым можно было бы оценить допустимость использования, в принципе не кто не исключает последующие заимствование кода из прототипов, так же как и разрастание проекта. Ну это ИМХО.
kkolyan
> 3. очень общие утилитарные классы типа Convert и Math.
> 4. Фабричные методы билдеров и DTO-шек. Но тут важно, чтобы метод отвечал
> только за создание корректного инстанса. Т.е. это по сути конструктор с именем
> и валидацией комбинации параметров. Здесь не должно быть никакой дополнительной
> логики.
С этим полностью согласен. Даже хотел привести в пример именно фабричные патерны. На мой взгляд статика на них ложится очень хорошо.
kkolyan
> 5. Создание своего DSL для использования в обособленных "портяночных" классах.
Про это я вообще не в курсе, почитаю вики.
kkolyan
> 6. метод с модификатором private.
> 7. метод с модификатором internal, если это алгоритм скопипащенный из сишного
> кода. для таких случаев уместно и сохранение оригинального форматирования.
Тут ХЗ
Jeners
> Не согласен, на мой взгляд это не тот критерий которым можно было бы оценить
> допустимость использования, в принципе не кто не исключает последующие
> заимствование кода из прототипов, так же как и разрастание проекта. Ну это
> ИМХО.
мне кажется, вы не совсем понимаете что такое прототип. Прототип - это не просто первая версия проекта. Это по-умолчанию черновик, нужный для быстрой проверки идей. Замедлять разработку прототипа вниманием к качеству кода - это может очень не понравиться тому, кто за разработку этого прототипа платит, т.к. промедление может вылиться в гораздо большую упущенную выгоду, чем стоимость переписывания прототипа (например дать конкуренту занять нишу).
> заимствование кода из прототипов
ну я заимствую код из постов на stackoverflow или туториалов, которые порой даже не компилируются. И что? Если вы заимствуете из прототипа большой кусок кода, то это должно сопровождаться рефакторингом, и не наоборот.
> так же как и разрастание проекта.
это порождает в итоге адовое говнище, выливающееся в серьезную копеечку в перспективе. если для заказчика бюджет что-то значит, проект в темпе переписывают с нуля, заменяя разросшийся прототип целиком, или по частям.
Иными словами - это нормальный сценарий, когда доработанный (но все еще говнокодистый) прототип какое-то время крутится в продакшне.
kkolyan
> мне кажется, вы не совсем понимаете что такое прототип. Прототип - это не
> просто первая версия проекта. Это по-умолчанию черновик, нужный для проверки
> идей. Замедлять разработку прототипа вниманием к качеству кода - это может
> очень не понравиться тому, кто за разработку этого прототипа платит, т.к.
> промедление может, например, дать шанс конкурентам сделать то же самое быстрее.
Да нет, мы вполне одинаково воспринимаем этот термин. Я не согласен с тем что это не тот критерий которым можно обосновать причину использования статик класса. Но как я и сказал это ИМХО.
kkolyan
> ну я заимствую код из постов на stackoverflow или туториалов, которые порой
> даже не компилируются. И что? Если вы заимствуете из прототипа большой кусок
> кода, то это должно сопровождаться рефакторингом, и не наоборот.
А почему оно должно сопровождаться рефакторингом? Разве вы не топите за то что-бы делать сразу правильно? Если есть возможность то почему не сделать класс и логику сразу красивыми?
И да, я лично стараюсь делать классы максимально утилитарными и сильно не связными.
kkolyan
> это порождает в итоге адовое говнище, выливающееся в серьезную копеечку в
> перспективе. если для заказчика бюджет что-то значит, проект в темпе
> переписывают с нуля, заменяя разросшийся прототип целиком, или по частям.
Это при условии если писать изначально в виде адового говнища =)
Jeners
> это не тот критерий которым можно обосновать причину использования статик
> класса
это критерий, которым можно обосновать любые недостатки кода, не противоречащие целям конкретного прототипа. почему неуместное применение статиков - исключение?
Jeners
> А почему оно должно сопровождаться рефакторингом? Разве вы не топите за то
> что-бы делать сразу правильно? Если есть возможность то почему не сделать класс
> и логику сразу красивыми?
Нет, в общем случае - не топлю, все ситуативно.
Jeners
> Это при условии если писать изначально в виде адового говнища =)
нет. сложность растет экспоненциально. на этапе готовности прототипа как прототипа качество еще будет просто плохим, что вполне нормально для прототипа.
Вы точно все читаете что я пишу?
> Замедлять разработку прототипа вниманием к качеству кода - это может очень не понравиться тому, кто за разработку этого прототипа платит, т.к. промедление может вылиться в гораздо большую упущенную выгоду, чем стоимость переписывания прототипа (например дать конкуренту занять нишу).
Вы правда готовы сидеть и наводить красоту в коде, когда за стеной ходит кругами менеджер и сгрызает ногти пытаясь понять, когда лучше релизиться - сейчас с жесткими багами или завтра пофиксив парочку, рискнув уступить нишу конкурентам, что может впоследствиии грозить закрытием студии?
kkolyan
> это критерий, которым можно обосновать любые недостатки кода, не противоречащие
> целям конкретного прототипа. почему неуместное применение статиков -
> исключение?
Ладно, скажу так - этот критерий просто "Необъективен". И им можно объяснить абсолютно любое говно, так что он просто не интересен сам по себе как критерий.
kkolyan
> Вы точно все читаете что я пишу?
Да читаю, и даже знал, что вы с акцентируете именно на этом пункте внимание. Но все равно я не считаю снова таки что это повод для писания говнокода.
kkolyan
> нет. сложность растет экспоненциально. на этапе готовности прототипа как
> прототипа качество еще будет просто плохим, что вполне нормально для прототипа.
Возможно мы с вами используем разные подходы в проектировании, но я лично стараюсь максимально изолировать элементы друг от друга. И сложность экспоненциально не растет.
kkolyan
> Вы правда готовы сидеть и наводить красоту в коде, когда за стеной ходит
> кругами менеджер и сгрызает ногти пытаясь понять, когда лучше релизиться -
> сейчас с жесткими багами или завтра пофиксив парочку, рискнув уступить нишу
> конкурентам, что может впоследствиии грозить закрытием студии?
Оу, если честно я считаю что лучше делать качественно, но я как правило работаю над внутренними проектами, и мне просто конкуренция такого вида не знакома.
С другой стороны я все равно считаю что играть в рулетку не лучший вариант.
Jeners
> Ладно, скажу так - этот критерий просто "Необъективен". И им можно объяснить
> абсолютно любое говно, так что он просто не интересен сам по себе как критерий.
очень для многих это предельно понятный критерий. для вас могу переформулировать его как:
2. код который по не зависящим от программиста причинам надо написать очень быстро любой ценой.
Jeners
> Возможно мы с вами используем разные подходы в проектировании, но я лично
> стараюсь максимально изолировать элементы друг от друга. И сложность
> экспоненциально не растет.
ключевое слово "стараюсь". я "стараюсь" не опаздывать на встречи, вовремя списывать время, опускать стульчак и т.п.
Но на практике, при увеличении системы по мере течения времени, маленькие недочеты накапливаются и потом самому стыдно смотреть. И это даже без учета командной работы. А с ней все смело умножаем на факториал от кол-ва членов команды. Боюсь, вы просто не дошли до того диапазона экспоненциального графика, где он отличим на глаз от прямой с учетом погрешности оценки.
Держать под контролем процесс разработки больших проектов эффективно можно только четкими правилами. Да, четкость всегда будет субъективна, но "стараюсь делать хорошо" это гораздо более общая и субъективная характеристика, чем даже самый субъективный из приведенных мною пунктов.
kkolyan
> 2. код который по не зависящим от программиста причинам надо написать очень
> быстро любой ценой.
Типо колоти говно щаз, а потом переделывай 10 лет?
Я наверное реально тупой, но как раз вот этой позиции я не разделяю.
Это прямой вред как бизнесу так и разработке, пусть бизнес это и ни когда и не поймет.
Jeners
> Типо колоти говно щаз, а потом переделывай 10 лет?
Есть 3 причины колотить говно:
1. нужно проверить очередную идею. высок риск что прототип покажет несостоятельность идеи и код уйдет в мусорку. Вложение сил на хороший код здесь неуместен. Можно сказать что "у меня рука набита делать хорошо", но во-первых, не верю. Во-вторых, даже если так, то рука у вас набита для определенного класса задач, а прототип зачастую проверяет что-то новое, а значит и привычный вам дизайн скорее всего окажется для этой задачи неудачным и вам для того чтобы сделать задачу хорошо, придется думать, т.е. тратить деньги заказчика на то, чего он не просил.
В случае удачного прототипа, на него выделяется отдельная команда с отдельным бюджетом и они пишут уже все хорошо (если смогут, конечно).
2. нужно занять нишу на рынке. уже писал выше. если проект не выстрелит - код все равно на свалку.
Если выстрелит - мы в шоколаде и нет никаких проблем переписать с нуля хорошо. Если проект небольшой, можно и отрефакторить, а не переписывать. Но после занятия ниши.
3. жадность заказчика.
пункт 3 живет, пока есть посредственные прогеры, желающие кушать. я его не поддерживаю ни коим образом (пока есть работодатели, считающие меня неплохим прогером, бгг).
Пункт 1 и пункт 2 - вполне стандартная, обоснованная и экономически и технически практика. особенно в геймдеве. Она совершенно не противоречит написанию хорошего кода (большую часть времени). Даже более того: без этих двух пунктов многие проекты бы просто не имели бы бюджетов, чтобы писать код хорошо.
kkolyan
Ладно фиг с ним, я согласен что уместно делать говно код для прототипов. Но не в коем случае я не поддерживаю точку зрения которую всегда навязывает бизнес, а именно -
"Сделай лишь бы работало, если что переделаем". На мой взгляд это крайне мерзкая практика, особенно когда код куда-то интегрируется в последствии.
Я допускаю что прототип можно писать как попало, я так же допускаю последующий его рефакторинг, я так же блин допускаю что даже хороший код можно отрефакторить.
Но я еще раз говорю, что это не тот фактор который мне интересен для случая применения статических классов.
Скажем так - вопрос изначально подразумевал под собой, что речь идет не о прототипах а об вполне рабочих готовых решениях. Не будем упираться на этот счет, но для меня реально это не тот фактор который можно рассматривать для применения статиков, как я уже и писал под этот фактор можно списать любое говно.
Jeners
> "Сделай лишь бы работало, если что переделаем". На мой взгляд это крайне
> мерзкая практика, особенно когда код куда-то интегрируется в последствии.
да, это мерзко(
Jeners
> опрос изначально подразумевал под собой, что речь идет не о прототипах а об
> вполне рабочих готовых решениях.
это вопрос к ТС, что он подразумевал. На мой взгляд, он подразумевал программирование на языке C#, которое в себя много что включает, т.к. язык довольно универсальный.
Спасибо всем за ответы. Все прочитал. истина рождается в споре.
Речь про язык C#.
Сейчас пробрасываю зависимости через создание класса и Zenject.
Поэтому и задался вопросом, нормально ли что класс например CoinController при создании получает 6! зависимостей, в том числе одна из них AudioManager, или логичнее было бы сделать его статиком и не пробрасывать.
Но тут логически мы понимаем вред статика, допустим мы открыли класс 100-200 строк, и мы никак не поймет сразу что где то на 187 строке идет статик вызов AudioManager.Play.., а если через зависимости, мы это видим сразу в конструкторе.
Ну про статик и запрет наследия всё понятно и так, но тут для меня вопрос будет ли когда либо наследие AudioManager для "расширения класса" или лучше добавлять функционал в сам класс AudioManager.
Делаю в первую очередь для общей либы на все проекты.
ЕЩЕ РАЗ ВСЕМ СПАСИБО, всех люблю
IgorkaNorka
> будет ли когда либо наследие AudioManager для "расширения класса" или лучше
> добавлять функционал в сам класс AudioManager.
не очень понял. не могли бы переформулировать?
kkolyan
Ну я имел ввиду что один из минусов статик классов, нельзя сделать наследие / расширение
public static class LOL { } мы не можем LOLExt : LOL
Но вопрос в том на примере AudioManager, НУЖНО ли это наследие? Или логичнее просто добавлять функционал в сам AudioManager. Нежели делать типа AudioManagerExt : AudioManager
IgorkaNorka
понял вас. не нужно)
во-первых, наследование как механизм развития класса - в принципе мера так себе. Наследование обычно применяется когда надо сделать несколько похожих, но по своему специализированные реализаций. Например DxRenderer, OpenGLRenderer или WindowsUIToolkit, GnomeUIToolkit. А для простого случая, когда у вас есть некий AudioManager прямо в вашем коде, и вы хотите его улучшить (добавить метод, уместный для этого класса) - да, просто его улучшаем и все)
во-вторых, программистское сообщество пришло к тому, что композиция почти всегда лучше наследования (и это не хипстерское веяние). Т.е. если раньше субклассы наследовали общее поведение у базового класса, переопределяя какие-то ключевые ньюансы (или определяя, если базовый класс абстрактен), то согласно принципу композиции, разные специализированные "субклассы" не имеют общего базового класса (только Object), а имплементируют один и тот же интерфейс. А общий функционал (то, что раньше было в базовом классе) выносится вообще в отдельный класс, ссылка на инстанс которого внедряется в оба "субкласса". Хотя именно это уже вариативно - например класс с общим функционалом может создаваться самим "субклассами" с правильными параметрами, или иногда общий функционал можно и продублировать (например это нормально, если классы находятся в разных проектах).
почитайте по ключевым словам "composition over inheritance".
Тема в архиве.