хотел спросить play или wicket?

Ох и выбор, прямо только эти два доступны?

а как ты их от результата отличаешь

по типу, там есть try/catch

по типу, там есть try/catch

и это ты считаешь без сайд-эффекта?

мне просто сложно понять, как жить без сайд-эффектов, по-сути, всё, что за приделами твоей вм, потециально ломает всю твою систему

мне просто сложно понять, как жить без сайд-эффектов, по-сути, всё, что за приделами твоей вм, потециально ломает всю твою систему

а кто-то говорил про то что можно в принципе обойтись без сайд эффектов?

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

ну то есть если в системе нет сайд эффектов то она не может никак взаимодействовать с внешним миром. Как минимум на границе между внешним миром и системой должны быть штуки которые вызывают сайд эффекты

оу, прости, немного перекосило меня, сделал равенство оброботки ошибок без сайд эффектов и работы системы в целом

ай все говно

никто не хочет похоливарить на тему иммутабельность vs инкапсуляция?

Мне нравится тема холивара. Тоже интересно. Иммутабильщики многие объекты состояния просто хранят в структурах и отдают в чистую функцию, которая вернет им новую структуру

https://habrahabr.ru/post/326620/

Мне нравится тема холивара. Тоже интересно. Иммутабильщики многие объекты состояния просто хранят в структурах и отдают в чистую функцию, которая вернет им новую структуру

Меня как ООП фаната это прямо таки коррежет и мешает мне писать истинно функциональный код с хранением состояния в типе структуры

Меня как ООП фаната это прямо таки коррежет и мешает мне писать истинно функциональный код с хранением состояния в типе структуры

может пора перестать быть фанатом?

@GnuFreedom а ты на пхп случаем не пишешь?

@GnuFreedom а ты на пхп случаем не пишешь?

А тебе зачем?

значит ты другой Сергей Журавлев)

Пока народу привалило повторю в надежде вопрос: никто на delphi/lazarus tiOPF не использовал?

я бы хотел посоветовать тебе спец. чатик, но сомневаюсь в его существовании...

значит ты другой Сергей Журавлев)

Я уж было чуть не обиделся) Мол, говорят, программист то не настоящий.

ой, ну народу привалило)

о, даже @Ai_boy

о, даже @Ai_boy

А я вообще не знал про группу :)

Чот давно труъ разговоров за ООП не было, я соскучился

где проспамили?

Как на счет обсудить такой подход: Все что в интерфейсе то паблик, все остальное либо привей, либо протектед?

Чот давно труъ разговоров за ООП не было, я соскучился

Начинай.

Как на счет обсудить такой подход: Все что в интерфейсе то паблик, все остальное либо привей, либо протектед?

Зачем? Я не вижу смысла в этом.

Зачем? Я не вижу смысла в этом.

Почему, будешь передавать в метод интерфейс, а там юзать только то что можно. А не всякие там сетеры и гетеры, не пощищь же их в интерфейс,лол. Получается и объекты будут иммутабельные.

Почему, будешь передавать в метод интерфейс, а там юзать только то что можно. А не всякие там сетеры и гетеры, не пощищь же их в интерфейс,лол. Получается и объекты будут иммутабельные.

Дык чем это ограничивает на паблик методы?

как-то все зауши притянуто

Ну, можно и так. Почему додполнительных не надо.

протектед вообще зло

протектед вообще зло

Почему?

ога потому что наследование нужно редко

^

ломает инкапсуляцию ж

Почему?

наследование, в большинстве случаев не правильно юзают )

наследование в классах, не в интерфейсах)

Почему, будешь передавать в метод интерфейс, а там юзать только то что можно. А не всякие там сетеры и гетеры, не пощищь же их в интерфейс,лол. Получается и объекты будут иммутабельные.

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

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

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

interface Stack<T> { push(element: T): void pop(): T }

interface Stack<T> { push(element: T): void pop(): T }

а вы с Коняшей не надумали насчет парного погромирования?)

interface Stack<T> { push(element: T): void pop(): T }

пример интерфейса без сеттеров, реализации которого подразумеваются мутабельными

Чот вы хрень какую-то обсуждаете.

а вы с Коняшей не надумали насчет парного погромирования?)

ну пока еще нет

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

А я вообще не знал про группу :)

ну вот велком)

пример интерфейса без сеттеров, реализации которого подразумеваются мутабельными

Хороший пример, но подразумевал дто

Хороший пример, но подразумевал дто

зачем для dto интерфейсы О.О

там просто public/readonly поля ж обычно, не?

Кстати да, поясните за иммутабильные GUI. Принцип работы и куда копать?

протектед вообще зло

почему?

А что тут ивент может быть по программингу ???

почему?

ломает инкапсуляцию

ломает инкапсуляцию

можно пример на с++

можно пример на с++

Протектед плох в случае, если методы не чистые.

Тебе нужно знать все сайд-эффекты знать, потому что ты можешь сломать всё. Сейчас пример набросаю.

можно пример на с++

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

чем тебе не пример "сломанной инкапсуляции"

ERROR: S client not available

Как правильно идти с самим собой на компромисы по архитектуре/коду, что бы потом не была попаболь, как вы принимаете такие судьбоносные решения? и как часто по итогу они приводили, не туда куда хотелось бы изначально?)

чем тебе не пример "сломанной инкапсуляции"

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

там просто public/readonly поля ж обычно, не?

Так то да. Согласен мутабельность с интерфесом не связан, это я погорячился)

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

какая разница если типы разные

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

по сути protected штуки становятся частью контракта

и часто - совершенно случайно

ну то есть protected это как goto - по дефолту лучше не юзать но иногда удобно

а люди которые по дефолту лепят protected всего-лишь носители культа карго

а люди которые по дефолту лепят protected всего-лишь носители культа карго

ну не сказал бы, что это культ карго

А люди которые по дефолту лепят private & final к какому культу относятся?

тут либо не знают разницы с private(бывает и такое), либо в каком-то таком жестком легаси с наследованием это спасало)

А люди которые по дефолту лепят private & final к какому культу относятся?

тож карго, если просто лепят)

Можно лепить и со знанием дела )

Aleh, ты мне как раз и нужен)) если репозитории работают с сущностью (добавление, например) и мы имеем у сущности кучу связей. Весь тот код, который собирает конечный entity и передает в метод add() коллекции, это по праву должно лежать где? В командах? Команда получается принимает на вход массив с fk и прочими полями. Не нашел ответа в сорцах того поляка. Где не посмотри примеры без связей.

> это по праву должно лежать где? gateway, dao

> В командах? кто такие команды?

> В командах? кто такие команды?

Класс с handle, который диспатчится ларой

Класс с handle, который диспатчится ларой

явно не там

или ты про входящие данные запроса?

Почему?

если так то да

или ты про входящие данные запроса?

Именно

Почему?

Request -> controller -(input data)-> command handler -(Entity)-> repositry::add

хэндлер есть юзкейс

ну мол, "что надо сделать"

внутри "как надо сделать"