Для чего нужны статические методы?

В каком контексте?

да в любом. Когда их применение оправдано? Когда они - единственный способ?

Я контейнер и инверсию зависимостей везде использую, и как-то не нужны они совсем стали.

Я контейнер и инверсию зависимостей везде использую, и как-то не нужны они совсем стали.

Передумал?)

Чет глупость написал вначале

Вот есть у меня метод, который не использует this. Есть ли хоть одна причина делать его статическим?

не думаю

да в любом. Когда их применение оправдано? Когда они - единственный способ?

если ты не планируешь этому методу давать доступ к данным объекта - делай статическим.

если ты не планируешь этому методу давать доступ к данным объекта - делай статическим.

вот! зачем?

какая то неоднородность методов будет если один всего

но это не точно

Какой-нибудь фабричный метод объекта, который создает сам себя должен быть статичным

вот! зачем?

Есть две теории. Первая теория базируется на учениях МакКоннелла, Фаулера и Мартина. Вторая - на собственных эмпирических предпочтениях. Если ты больше тяготеешь к красивой и изящной стилистике и придерживаешься стайлгайдов - обращай внимание на контекст и соседние методы. А если ты пишешь сам по себе - делай как считаешь нужным. В любом случае будешь прав.

Какой-нибудь фабричный метод объекта, который создает сам себя должен быть статичным

Вот я тоже раньше так думал. Допустим, если у меня класс A и метод типа A.fromFoo() возвращает экземпляр A. А потом я взял и сделал B extends A. И теперь у меня B.fromFoo() возвращает все ттот же экземпляр A. Нелогично как-то.

Опять же, если ты говоришь в контексте джавы, то там понятно почему метод должен быть статичным.

Опять же, если ты говоришь в контексте джавы, то там понятно почему метод должен быть статичным.

ну будем говорить о java-подобных языках, которых много

ну будем говорить о java-подобных языках, которых много

Нет, я конкретно именно о Java. Модификатор static в Java напрямую связан с классом, если поле статично, значит оно принадлежит классу, если метод статичный, аналогично — он принадлежит классу. Исходя из этого, можно обращаться к статическому методу или полю используя имя класса.

в php можно через static вместо self возвращать B, а не A

В других языках это реализуется другими способами, а иногда пропускается вообще

В php можно вообще всё делать, там полная свобода.

Ну и опять же, если речь о компилируемых языках, то статический метод будет обрабатываться только в контексте конкретного класса. А не статический будет global wide

в php можно через static вместо self возвращать B, а не A

Не всегда. Но это не важно. Смежный вопрос: должны ли статические методы наследоваться?

Нет. Статические методы не должны наследоваться по-определению. Какой тогда в них смысл?

Хотя опять же, это в теории и по словам опытных товарищей, написавших много книжек по коду и его "красоте"

Ты в праве использовать любые стили. Хоть венгерскую нотацию, плевать.

Нет. Статические методы не должны наследоваться по-определению. Какой тогда в них смысл?

Ну вот мне тоже так кажется, иначе возникает дурацкая ситуация, которую я выше описал

да в любом. Когда их применение оправдано? Когда они - единственный способ?

Никогда, как и почти любой вещи)

Вот я тоже раньше так думал. Допустим, если у меня класс A и метод типа A.fromFoo() возвращает экземпляр A. А потом я взял и сделал B extends A. И теперь у меня B.fromFoo() возвращает все ттот же экземпляр A. Нелогично как-то.

Наследование -_____-

Я не понял смысла на самом деле того, что изображено

Я не понял смысла на самом деле того, что изображено

ну там не про статику же пример

вот! зачем?

Чтоб лишний объект не аллоцировать для вызова?

Искал про Late static binding в java, а его нет оказывается

обычно по долгу службы сталкиваешься с тем, что статика это в основном поганые хелпер классы, фасады и прочее

Чтоб лишний объект не аллоцировать для вызова?

нуууу... ооп и оптимизация по стеку/памяти это штуки из разных миров по-моему

под ооп я имею в виду обывательское понимание "как в жава"

под ооп я имею в виду обывательское понимание "как в жава"

можно пойти от обратного, что бы понять ответ на твой вопрос, когда нужен конкретно объект ?

можно пойти от обратного, что бы понять ответ на твой вопрос, когда нужен конкретно объект ?

объект нужен чтобы в рантайме его подсовывать, для DIP

чтобы связи в нужную сторону направить

принцип инверсии зависимостей

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

когда тебе сознательно нужно нарушить инкапсуляцию?:D

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

статические члены не являются частью интерфейса, насколько я понимаю

и будем считать, что у нас есть перегрузка методов, так что "именованные конструкторы из пхп" не нужны

и будем считать, что у нас есть перегрузка методов, так что "именованные конструкторы из пхп" не нужны

не совсем эквивалетная замена: new Busket и Busket.pick()

не совсем эквивалетная замена: new Busket и Busket.pick()

что делает pick()?

что делает pick()?

если в вашем домене покупатели берут корзины, то это ее взять)

если пользователи регистируются, то пусть это так и называется

если в вашем домене покупатели берут корзины, то это ее взять)

так она уже создана. они где-то сложены в кучу и покупатель ее берет? тогда почему не this.pileOfBaskets.pick()?

интересно как тогда в домене выглядит new Human(new Busket(new Product)))

так она уже создана. они где-то сложены в кучу и покупатель ее берет? тогда почему не this.pileOfBaskets.pick()?

нет, не создана до того, как ее возьмут

нет, не создана до того, как ее возьмут

т.е. цель - инкапсулировать процесс создания корзины?

т.е. цель - инкапсулировать процесс создания корзины?

цель метода или что?

или имени?

метода

да, создает корзину

получается, что он две вещи делает: 1) создает корзину и 2) назначает ее покупателю

так?

намек на SRP ?

в случае. когда этот бизнес-процесс именуют "покупатель взял корзину" или типа того

иначе в чем отличие от new?

названием

new не имеет отношения к домену, pick - имеет

а new вообще запрещен

ага как и class

приватный

call Bugaenko

класс можно)

а new вообще запрещен

ну я и говорю, ты хочешь скрыть процесс создания экземпляра козрины

ну и new можно, просто есть куча ситуаций, где можно гораздо лучше и достаточно дешево сделать)

ну я и говорю, ты хочешь скрыть процесс создания экземпляра козрины

не уверен, что я хочу его скрывать

я хочу дать ему имя)

тогда почему pick(), а не create()?

потому что бизнес говорит pick

это у них так называется

и когда новый разработчик будет спрашивать - ему объяснят

причем смогут объяснить даже не разработчики

это у них так называется

ну хорошо, принимается

то есть суть просто в переименовании "new" ради ubiquitous language

да

ну ок, соглашусь. хотя пример невероятный, как по мне)

наличие доменной области?))

нет, конкретно переименование операции new

Эт, доброй ночи :) Я влезу со своим, вы не против?)

доменный язык vs шок от приватного констркутора... ну хз такое себе

нет, конкретно переименование операции new

если эти методы у тебя first class, то вполне отлично blahblahblahWith(Buskcet.pick)

ну ок ок

я готов допустить, что где-то упарываются доменным дизайном до такой степени.

Вот есть у меня метод, который не использует this. Есть ли хоть одна причина делать его статическим?

Да - сделав его статическим, ты даёшь гарантии (enforced by compiler) что и в будущем "случайно" туда не просочится this. Таким образом ты усиливаешь инкапсуляцию, ограничивая доступ к данным объекта из метода, который и не должен бы этоми данными объекта пользоваться. (Предполагается, что неиспользоыание this является частью логики вычислений, и не появилось "случайно")

наверно можно и до такого докатиться, если все остальные проблемы решены

я готов допустить, что где-то упарываются доменным дизайном до такой степени.

это как раз очень малая степень упарывания практически ничего от тебя не требующая

ну т.е. можешь начать использовать прямо сейчас бесплатно, прям лайфхак)

ну т.е. можешь начать использовать прямо сейчас бесплатно, прям лайфхак)

хз. это как полировать одну доску в лодке, когда с другого борта дыра

мое мнение)

хз. это как полировать одну доску в лодке, когда с другого борта дыра

полировка это 100% кавередж и еще мутационные тесты проходят и даже где-то сбоку проперти проверяются

возможно просто у меня психика травмирована

а это задача минуты или 5