Какие-то вредные советы на оопшный лад, перевёрнутый мир, всё наоборот

ну мы щас рассматриваем альтернативы, они есть, хотя все тут утверждают что их нет

Ясно

вот эти все "ясно", "понятно"

а где конкретика почему так плохо делать?

аргументация?

ну от тебя её и ждут) почему это плохо в твоей картине мира) в разные вещи народ укпарывается, но что бы в конструкторы - эт впервые)

к конструктору куча вопросов: - метод ли это? (а должен ли?) - что делать с наследованием, полиморфизмом и другими LSP в отношении конструктора - если конструктор - это что-то из разряда жизненного цыкла обьекта, то что с этим делать? - как сделать без конструтора?

я же написал несколько раз уже

Попробуй говорить с собеседниками а не сам с собой)

вот да

1) да, метод) вызывается вслед за каким-то мифическим событием. 2) всё то же самое, что и всегда 3) понять и простить 4) хоть через рефлексию

чё дальше?)

дальше думать почему так

нахера?

чтоб моск развивать

если он канеш есть

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

а явно вызвать конструктор мне кто помешает?

я предлагал приватный конструктор и статический фактори метод

итак: - конструктор нарушает LSP почти всегда... это никого не интересует? - вызывать его как метод не имеет смысла, но он доступен как метод... это типа ок? - жизненный цыкл обьекта - это что-то новое, неизученное в ООП - есть отличный способ обойтись без конструктора-метода, например как в Scala

я перефразировал, надеюсь теперь понятно в чем боль

я предлагал приватный конструктор и статический фактори метод

это тоже интересная тема для дискуссий, особенно что такое "статический", и каким боком оно к ооп

итак: - конструктор нарушает LSP почти всегда... это никого не интересует? - вызывать его как метод не имеет смысла, но он доступен как метод... это типа ок? - жизненный цыкл обьекта - это что-то новое, неизученное в ООП - есть отличный способ обойтись без конструктора-метода, например как в Scala

еще раз) 1 - фактори метод может возвращать что угодно 2 - сделать приватным 3 - это не изучено в ООП потому что к ООП это никак не относится 4 - ну круто, молодцы

> 1 - фактори метод может возвращать что угодно именно! например что-то другое

я не хочу влезать в фактори-метод сейчас, это грустная тема...

это тоже интересная тема для дискуссий, особенно что такое "статический", и каким боком оно к ооп

к классу относится, к ооп вряд ли

и если уж предлагаются такие воркараунды с ним, то зачем тогда конструтор вообще? в фактори-методе можна и поля все установить

и если уж предлагаются такие воркараунды с ним, то зачем тогда конструтор вообще? в фактори-методе можна и поля все установить

лол нет, ридонли поля нельзя

для этого конструктор

а ридонли это какие? специальные readonly? не приватные?

Вот что случается с людьми в языках без функций as first class citizens

пхпшник не палится)

а ридонли это какие? специальные readonly? не приватные?

приватные методы не могут мутировать это поле

это в каком языке есть такое прикольное?

C#, TS еще думаю

В любом нормальном

везде где классы есть же?

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

readonly > private set > public set, парад костылей

еще protected, sealed

а еще friend

ну ты чет путаешь

это уже про наследование

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

остальное тоже про доступ

ноуп, френд да, про доступ, но я не подразумевал его использование

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

особенно если мы можем вызвать конструтор явно второй раз и переопределить их....

и вообще почему эти поля можно записывать только в конструторе, а не просто "возможность записи один раз"

Обычно подобные диалоги ведут с уткой

Использовать чаты в данных целях неприлично))

и вообще почему эти поля можно записывать только в конструторе, а не просто "возможность записи один раз"

думаю надо начать с вопросов... broad api vs narrow api? (я сам тока что нашел это в инете, а слова специально на английском, чтоб побудить человека вдуматься и, еще, обойти ментальные триггеры на знакомые и замыленные слова)

думаю надо начать с вопросов... broad api vs narrow api? (я сам тока что нашел это в инете, а слова специально на английском, чтоб побудить человека вдуматься и, еще, обойти ментальные триггеры на знакомые и замыленные слова)

Interface Segregation Principle

я думал KISS

так где тут KISS? вызывам статический метод, чтоб он вызвал приватный конструктор, чтоб он засетил ридонли поля?

так где тут KISS? вызывам статический метод, чтоб он вызвал приватный конструктор, чтоб он засетил ридонли поля?

Сильна

и где здесь broad vs narrow?

так где тут KISS? вызывам статический метод, чтоб он вызвал приватный конструктор, чтоб он засетил ридонли поля?

отвечу, если получу ответ на свой вопрос

где вопрос? я только одно утверждение вижу, где в конце знак вопроса... но на вопрос не похоже

broad api or narrow api? choose your warrior :D

Interface Segregation Principle

а, да, верно

так где тут KISS? вызывам статический метод, чтоб он вызвал приватный конструктор, чтоб он засетил ридонли поля?

дай линк на сообщение в котором раскрывается каким образом конструктор нарушает LSP

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

дай линк на сообщение в котором раскрывается каким образом конструктор нарушает LSP

ну он не может более общий тип вернуть

все началось как раз с такого вопроса: абстрактный конструтор

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

а, ты о ситуациях когда мы овверрайдим конструктор?

именно

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

скорее не так

к слову - в контексте прототипного наследования ж нет проблемы с конструкторами и LSP

просто классы в разных языках - очень разные

просто классы в разных языках - очень разные

капитанское открытие)

ну я к тому, что кое-что устарело)

например, языки программирования

например, языки программирования

почитал труды Кея последние? тоже загорелся DSL и meta-meta языками?

еще нет, дай где)

но суть та, да

http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html

ну например из распиаренного вот это

типа реализация TCP/IP стэка в 200 строк

да, угу

только я шото не понял, это только концепция, или они уже пилят?

к слову - в контексте прототипного наследования ж нет проблемы с конструкторами и LSP

Прототипное наследование ещё суровее) По нездоровому так, по C++шному

Хотя как низкоуровневая база весьма эффективен

только я шото не понял, это только концепция, или они уже пилят?

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

Прототипное наследование ещё суровее) По нездоровому так, по C++шному

нипонятно... причем тут плюсы?

Ну как эталон монстроузных возможностей

Можно делать слишком невероятные вещи)

ну это к слову

а ну это да

По ссылке выше люди со своего угла зрения подходят к самой топовой сейчас идее

broad api or narrow api? choose your warrior :D

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

Sum type, dsl, case class, unions, free monads, даже конечные автоматы с натяжкой — это всё выражает одну и ту же идею

Sum type, dsl, case class, unions, free monads, даже конечные автоматы с натяжкой — это всё выражает одну и ту же идею

интересно... какую?

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

open-closed в широком смысле

это именно оно

Нет, это радикально иной уровень

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