Народ, есть валидация определенных значений, которая повторяется в нескольких местах (в контроллере, MVCS), нормально ли выносить ее в отдельный класс, дабы избежать дублирования? Учитывая, что это пока единственный подобный класс-валидатор в проекте

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

Народ, есть валидация определенных значений, которая повторяется в нескольких местах (в контроллере, MVCS), нормально ли выносить ее в отдельный класс, дабы избежать дублирования? Учитывая, что это пока единственный подобный класс-валидатор в проекте

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

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

low coupling, high cohesion

Ну это то понятно)

Ну это то понятно)

про каплинг и кохижен или про то что нормально дублирование выносить в отдельную хрень?

про каплинг и кохижен

если тебе все понятно то тогда как бы... и вопросов не должно возникать)

?

Народ, есть валидация определенных значений, которая повторяется в нескольких местах (в контроллере, MVCS), нормально ли выносить ее в отдельный класс, дабы избежать дублирования? Учитывая, что это пока единственный подобный класс-валидатор в проекте

я же тебе писал)

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

дык смотри во сколько я спросил)

ну я только заметил

надо пилить обучающие туторы)

ребятушки, доброй ночи

Тока без фп на пыхе, пожалуйста

на пыхе фп это нонсенс)

у меня даже доклад про это есть (спойлер)

на пыхе фп это нонсенс)

Хочу монад на пыхе

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

Ну, малеха ошибся я)

сегодня хочу по серьезному, без пыха

сегодня хочу по серьезному, без пыха

Ауч

сегодня хочу по серьезному, без пыха

это можно испортить одной фразой "пых красава"

Haskell в помощь, друг мой)

внимание, вопрос: что за хрень такая этот самый конструктор?

Госпади

А навеянно то чем? Пыхой !

не

Да пребудет с тобой присвятая лямбда)

навеяно каноничным ооп на классах

навеяно каноничным ооп на классах

Все мы знаем ответ...

наверное, действительно lifecycle event

хендлер тогда уж

навеяно каноничным ооп на классах

В шарпике кстати конструктор - не функция, в отличии от явки.

На него указатель взять нельзя(

хендлер тогда уж

угу

но все равно возникает несколько вопросов: - как быть с наследованием конструкторов? - как быть с LSP - обязательно лы вызывать конструктор парента - что вообще такое "метод"

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

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

есть идеи?

наследование конструкторов - цепочка хендлеров

c пропагацией

обязательно/нет - выплывает из предыдущего

не похоже на правду

не похоже на правду

не претендую)

еще мысли: - множественное наследование - diamond of death - интерфейс с описанием конструктора

еще мысли: - множественное наследование - diamond of death - интерфейс с описанием конструктора

Конструктор - это уже детали реализации. Интерфейс же это контракт по сути. То есть «дай мне что-то, что умеет вот это». А не «дай мне что-то, что создаётся вот так». Ну и опять же, нельзя же создать инстанс интерфейса, только класса, реализующего интерфейс. Так что интерфейсы конструкторов - такое... ПыСы - C#

https://www.youtube.com/watch?v=fhOHn9TClXY

тут немного истории, и меньше чем обычно возвышенных мыслей

это касательно моего вопроса о конструкторах?

или просто так?

можно и так сказать...

внимание, вопрос: что за хрень такая этот самый конструктор?

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

но все равно возникает несколько вопросов: - как быть с наследованием конструкторов? - как быть с LSP - обязательно лы вызывать конструктор парента - что вообще такое "метод"

- наследование конструкторов - ты их должен явно вызывать. Так что ничего сверх естественного. - прекондишены можно ослабить, пост кондишены усилить (но не уверен что оних можно говорить в контексте конструктора), инварианты оставить без изменений. - обязательно так как не вызывая ты можешь нарушить инварианты парента. - "метод" это процедура выполняемая в контексте какого-то инстанса данного класса. Понятие не имеющее к ООП никакого отношения и пришедшее из далеких 60-х из языков типа algog и simmula. и тут видос мой как раз подходит)

p.s. а почему тебя вообще этот вопрос стал заботить?

хочется понять что с ними не так

навеяно каноничным ооп на классах

Смалталком что ли

не, тут вопрос скорее о коплинге и кохижне

и о всякой инвариантности

Я хз, ты о чём-то сильно специфичном загоняешься

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

Хз в чем проблема вообще function Foo(bar: number) { return { bar, name: 'Foo', } }

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

Конструктор это функтор из Id в тип

о слишком толстый набросок )

?

Но так и есть

впринципе да но канал же об ооп )

?

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

Ну в ООП конструктор это конструктор

Но он спросил про альтернативы)

есть идеи?

???

еще мысли: - множественное наследование - diamond of death - интерфейс с описанием конструктора

конструктор с генериками в интерфейсе?

еще мысли: - множественное наследование - diamond of death - интерфейс с описанием конструктора

убери наследование — problem solved

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

ответь на вопрос - должен ли у "объекта" в общем смысле быть жизненный цикл?

ну то есть "начало" и "конец" жизни

Экзистенциальные вопросы пошли)

Конструктор это функтор из Id в тип

Есть буквы умные по этому поводу?

Функтор на категориях определён, а не на каком-то абстрактном айди и типах

А абстрактный id — это и есть то что определяет категорию саму по себе

Вернее там ещё как-то можно через магму определить, но я в это лезть не рискнул)

А абстрактный id — это и есть то что определяет категорию саму по себе

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

Здорово, но к чему это

это к тому, что "абстрактный id" - это непонятно что

Ну раз не понятно то стоит изучить

что именно? я в курсе что такое id, но я не в курсе что это за "абстрактный id — это и есть то что определяет категорию саму по себе", потому что это какой-то бред)