мне такой подход тоже кажется верным. еще одна причина для этого - фреймворки. взаимодействие с транспортным уровнем (веб, api, GUI, cli) как правило очень хорошо реализовано готовыми библиотеками. и, опять же, как правило, контроллеры довольно тесно связаны с фреймворками. ядро бизнес-логики должно быть независимо от фреймворка и от механизма доставки.

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

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

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

Для каждого поля есть валидаторы. После в цикле всё проверяешь.

валидация - ответственность контроллера, в модель валидацию пихать не стоит, в модели только бизнес логика

валидация - ответственность контроллера, в модель валидацию пихать не стоит, в модели только бизнес логика

Но валидация проверяет условия, которые относятся к предметной области (скажем, что uid число и > 0 или что имя не может быть пустым).

ну да, такую валидацию уже в модель, она к ней относится

Вот конвертация — другое дело. Где-то она нужна (веб-форма какая-то), а где-то нет (скажем qt поле какое-то), так что это логично иметь в контроллере

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

А что такое инпуты юзера? не модель ли?

тогда возникает вопрос: как контроллер должен валидировать правильность модели...?

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

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

ппц, и сюда di притащили

ну а чо, модно же ©

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

т.е. валидация происходит 2жды?

ну да, в контроллере общая валидация, без знания правил, в модели валидация, привязанная к бизнес логике, т.к. модель знает больше о своих полях

Di в модель передает О.о

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

в контроллере валидируются данные относящиейся к application layer, в модели конкретно к business layer этой модели. Т.е. если есть валидация пароля, привязанная к модели, то она там и валидируется. А вот какое-нибудь поле password_should_be_confirmed или csrf токен уже в контроллере, т.к. мы в будущем можем добавить другие модели, где это поле не нужно

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

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

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

А то скажите что наследование в принципе зло))

Если что, customobject является наследником более общего абстрактного объекта интерфейсного

почему не взять композицию?

Началось

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

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

принцип лисков соблюдается

/stat@combot

combot.org/chat/-1001071233926

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

Можно внутри держать мапу

Искать по ней

Можно список туплов: <критерий, значение>, где критерий - это функция, которые принимает на вход какие-то параметры

Искать можно до первого попавшегося критерия

Можно список туплов: <критерий, значение>, где критерий - это функция, которые принимает на вход какие-то параметры

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

ну да, банда четырёх вполне под детскую лит-ру подходит

как ее по акции прикупить?

http://www.labirint.ru/books/87603/ уже другая какая-то акция

как в целом книжка?

По моим воспоминаниям - одна из лучших книг про практику ООП вообще.

/me ожидает забрасывание помидорами на тему "паттерны это вообще не ООП"

на самом питере она дешевле

https://www.piter.com/collection/all/product/priemy-obektno-orientirovannogo-proektirovaniya

я вот эту еще заказать хочу https://www.piter.com/collection/biblioteka-programmista/product/ekstremalnoe-programmirovanie-razrabotka-cherez-testirovanie

XP оно немного про другое, и даже не факт что про ООП

По моим воспоминаниям - одна из лучших книг про практику ООП вообще.

это справочник, а не учебник

да, в некотором роде даже "сборник рецептов" - типа "в таких случаях неплохо работает такое вот..."

Господа, положим вы тащите rss-ки и у постов может быть описание (почти всегда есть). Стоит ли в базе различать пустое описание и NULL или нет (то есть хранить с NOT NULL DEFAULT '')? Дискасс

ну тебе надо отличать null от ''?

Аналогичный вопрос про теги (пустой массив и NULL)

ну тебе надо отличать null от ''?

Вопрос не в том, надо ли мне. Очевидно, что не надо Вопрос в том, логически в данном случае это одно и то же или нет

раз не надо, значит одно и то же

у RDBMS иногда индексы по-разному работают для nullable полей

но я не понимаю, какое это имеет отношение к ооп

Ну, блин. Это разница — между Maybe String и String

ну ты сказал, что бизнес-логика этой разницы не понимает

значит пофигу

ERROR: S client not available

у RDBMS иногда индексы по-разному работают для nullable полей

ну, это КО. И в случае со строкой может менее эффективно получиться

@mkusher что думаешь?

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

Неспортивный ответ

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

хоть ты в текст жсон пихай)

Да забудь ты про БД. Пусть это не БД, а так, локальный тип. Поставим вопрсо так: нужно ли преобразовывать Maybe String в String, если бизнес-логике не нужно их различать?

думаю да

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

как оно у тебя там " по умолчанию"? так и делай

Да, но может быть не пустое описание, а состоящее только из пробелов. Не логичнее ли тогда сводить все незначащие описания к Nothing, нежели наоборот?

Ну, то есть на самом деле тебя интересует есть ли описание, а не "длина описания = 0". С этой точки зрения правильнее сводить не Nothing к пустоте, а пустоту к Nothing.

Пля, не надо было пить сегодн

сколько данных?

Речь не о производительности.

Хотя доводы выслушаю, если знаешь что будет быстрее.

Вангую, что со строками будут быстрее NULL-ы, а с численными типами — сведение к 0.

у тебя мускуль?

Нет, посгрес

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

вот чувак правильную вещь написал

Не, это ответ кодера

Где тут программисты, которые за логику пояснят

Потому что мне вот кажется, что надо сводить к Nothing, наоборот.

https://t.me/pgsql

Причём тут это?

Зря я БД приплёл, разговор исключительно о типах

я бы к null сводил

// но за чатик спасибо

я бы к null сводил

Тогда следующий вопрос, уже бд касается, ага: стоит ли в этом случае накладывать ограничения в БД, например (CHECK(length(description) > 0) или вообще с регулярочкой?

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