Ты же сам ответил, не хранит стейта

и что? он делигирует работу другим объектм которые хранят стэйт

и что? он делигирует работу другим объектм которые хранят стэйт

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

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

ты вызываешь метод объекта, тебе важно есть там стэйт или нет? или тебе важно только поведение?

Ты уходишь не туда

ты не можешь этого знать)

туда или не туда

Проведи аналогию функция == объект

зачем?) это тупо и в этом нет смысла

объект = функция. Есть объекты со стэйтом (монады например) и без стэйта (функции просто)

Это твоё утверждение, я с ним не согласен, провести конкретную аналогию ты так и не смог

что тебе еще надо?)

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

а это не совсем так, стэйт это деталь реализации, нам важно только поведение

так что "объект это любая хрень которая что-то делает"

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

так что "объект это любая хрень которая что-то делает"

А, ну норм

ты можешь работать с функцией как со значением

а можешь как с поведением

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

В таком случае естессно

можешь делать композицию функций так же как композицию объектов

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

Но что бы ты не считал, функция так и не станет объектом, увы или нет, уж не знаю)

Но что бы ты не считал, функция так и не станет объектом, увы или нет, уж не знаю)

ну... щито поделать. Ладно, тогда удачи

ну... щито поделать. Ладно, тогда удачи

Спасибо, если без лукавства, и тебе)

и я повторюсь - какой-нибудь сервис предоставляющий поведение но не хранящий никакого стэйта - это объект или нет?

стейта допустим нет, но сервис может упасть, и быть доступным, вот и стейт.

стейта допустим нет, но сервис может упасть, и быть доступным, вот и стейт.

что значит "упасть"?

Ну например есть какая то страница на вики к примеру которая всегда отдаёт один и тот же результат по GET вдруг что то случилось с сервером и на запрос этой страницы я получаю 500 код.

это немного не тот "сервис")

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

пример - паттерн стратегия

Откуда вы, люди?

монады очень похожи на объекты по своей сути

Это и есть объекты с очень конкретным интерфейсом

Потому что функция не объект

ну теперь все ясно

Потому что функция не объект

http://sandbox.onlinephpfunctions.com/code/05fffc345b2099d3446067d2e67a5bfbf45036cb http://php.net/manual/ru/functions.anonymous.php Анонимные функции реализуются с использованием класса Closure.

http://sandbox.onlinephpfunctions.com/code/05fffc345b2099d3446067d2e67a5bfbf45036cb http://php.net/manual/ru/functions.anonymous.php Анонимные функции реализуются с использованием класса Closure.

Так это просто реализация объекта в виде функции, но это не делает просто отдельную функцию объектом

Ну, любое замыкание будет экземпляром класса Closure. Особенность реализации.

Да

/stat@combot

combot.org/chat/-1001071233926

Objects are poor man's closures

?

спор такой был и никто не процитировал

или наоборот? ?

или наоборот? ?

не, никто не процитировал но цитата хорошая)

Вот такой вопрос. Есть Exception которые бросаются на уровне моделей. Что-то типа ConfirmationTokenExpiredException. Они у меня находятся в папочке Model. А есть exception которые кидают сервисы. Есть сервисы уровня приложения, (Генерация превьюшек, объедение операций и т.д.). Какие exception должны кидать сервисы? Я думаю что я что-то не так делаю и у меня нет правильно понимания

Или вот есть сервис по работе с изображениями. От него зависят несколько фич (Пользователь, Посты и т.д). Для таких сервисов нормально создавать отдельную директорию (Common), где можно складировать эти сервисы плюс exception, которые могут они кидать , тогда я беру и создаю под такие сервисы интерфейсы, которые используются в сервисах фич?

Или не сюда такие вопросы задавать)

Вот такой вопрос. Есть Exception которые бросаются на уровне моделей. Что-то типа ConfirmationTokenExpiredException. Они у меня находятся в папочке Model. А есть exception которые кидают сервисы. Есть сервисы уровня приложения, (Генерация превьюшек, объедение операций и т.д.). Какие exception должны кидать сервисы? Я думаю что я что-то не так делаю и у меня нет правильно понимания

Папочка Model это как-то не правильно имхо. Лучше группировать по фичам, а не так.

Папочка Model это как-то не правильно имхо. Лучше группировать по фичам, а не так.

Ну меня как то так щас

Или вот есть сервис по работе с изображениями. От него зависят несколько фич (Пользователь, Посты и т.д). Для таких сервисов нормально создавать отдельную директорию (Common), где можно складировать эти сервисы плюс exception, которые могут они кидать , тогда я беру и создаю под такие сервисы интерфейсы, которые используются в сервисах фич?

Чем меньше сервисы знают друг о друге тем лучше (low coupling) а пакет common как то дурно пахнет как по мне, пусть исключения у каждого пакета будут свои, не нужно так "переиспользовать" код

Тогда и исключения и модели и сервисы и все остальное, что относится к фиче, будут вместе

Это фича

Отдельная папка с исключениями это дурной тон

Отдельная папка с исключениями это дурной тон

Я согласен. Равно как и DTO

Я согласен. Равно как и DTO

Хмм держать все на одном уровне, тоже каша получится

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

Ну я собирал данную структуру исходя из контекста

dto, event, entity для меня все это неотъемлемая часть модели

А вот сервисы у меня на уровне фичи, так они больше собирательный образ

Я согласен. Равно как и DTO

Вот только на что заменить Dto вот в чём вопрос) у меня было здесь предложение, если уже есть Dao и dto то можно схитрить и прописать методы Dao в Dto т.е. crud методы, потом внутри dto делегировать всю работу по круду в Dao которое будет полем Dto таким образом Dto станет полноценным обьектом, а вся работа с базой данных по прежнему будет в Dao.

Вот только на что заменить Dto вот в чём вопрос) у меня было здесь предложение, если уже есть Dao и dto то можно схитрить и прописать методы Dao в Dto т.е. crud методы, потом внутри dto делегировать всю работу по круду в Dao которое будет полем Dto таким образом Dto станет полноценным обьектом, а вся работа с базой данных по прежнему будет в Dao.

Я тут не готов спорить.

У меня dto больше нужны для того чтобы кидаться между сервисами, плюс в них описаны правила валидации. То есть я принимаю в экшене дто'шку, валидирую ее и кидаю в сервис

Хмм держать все на одном уровне, тоже каша получится

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

Вот только на что заменить Dto вот в чём вопрос) у меня было здесь предложение, если уже есть Dao и dto то можно схитрить и прописать методы Dao в Dto т.е. crud методы, потом внутри dto делегировать всю работу по круду в Dao которое будет полем Dto таким образом Dto станет полноценным обьектом, а вся работа с базой данных по прежнему будет в Dao.

row data gateway?

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

Не совсем понял в чем моя ошибка?)

Не совсем понял в чем моя ошибка?)

В папке моделей получается лежать только сущности и репо? Все остально выносится на уровень выше. И Exceptionы уровня сервисов буду лежать среди exception отоносящихся к сущностям?

row data gateway?

Вот уже и паттерн оказывается готовый есть, только я думаю что иметь на каждый экземпляр dto свой инстанс гейтвея как то не очень, лучше тогда уже пусть будет традиционный dao в самих dto (один на всех) плюс так можно быстро рефакторить уже имеющийся код, просто спрятав dao но не удаляя его.

Вот уже и паттерн оказывается готовый есть, только я думаю что иметь на каждый экземпляр dto свой инстанс гейтвея как то не очень, лучше тогда уже пусть будет традиционный dao в самих dto (один на всех) плюс так можно быстро рефакторить уже имеющийся код, просто спрятав dao но не удаляя его.

ну ты описание глянь лучше, ибо я не уверен что правильно тебя понял