можешь с примером? Это аналог Maybe?

Это что-то аля Optional[T] у которого есть два наследника Some[T] и None[Nothing]

юзают для работы с null

ага, короче Maybe из haskell

type Maybe a = Just a | Nothing

ну я не силён в хаскеле 😁

type Maybe a = Just a | Nothing

похоже

ну, если null воспринимать как Nothing, то type Optional<T> = T | null;

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

там есть просто strictNullChecks

+ orElse, orThorw

я вообще про опшнал оператор, как в свифте или котлине

Nothing просто bottom type для всех типов

идея ж ts & flow, не эмитить ничего лишнего в рантайм

type A = { a?: number } - здесь поле a необязательное

nullable типы в котлине удобнее ведь монад

в ts короткий синтаксис для T | null | undefined не добавили, а в flow есть ?T

Здравствуйте! не надется яминутки поговорить об ООП?

Короче есть три разных сущности (class CModel yii1) свойства которых(поисковые параметры) частично пересеаются. Я хочу написать гибкий и удобный расшияемый поиск. Пока думаю создать интерфейс SearchInterface его реаализовывать в каждом из классов поиска под конкретную сущность. Также как вариант думаю создать интерфейс SearchebleItemInterface и реализовать его в каждой из модели, чтобы поиску было удобнее работать с ними. На данный момент все реализовано для кжадой сущности в контроллере вызывающим метод модели формы сущности что не очень верно най мой взгляд, но удобно для работы с пользовательскими данными. Вобщем буду рад конструктивным идеям и предложениям, т.к пока в голове каша + ситуация усугублятеся тем что yii я не очень знаю(совсем)

Казалось бы при чем здесь ооп?

Опиши задачу без привязки к языку и фреймворку

Здравствуйте! не надется яминутки поговорить об ООП?

Это пять :)

Я сразу подумал про паттерн Visitor (GoF).

есть похожие, но различающиеся сущности. К примеру СТО и МагазинЗапчастей. Под каждую сужность нужен свой раздел поиска. То есть каждый поисковой запрос нужно обработать и выбрать подходящие сущности. на даннымй момент весь код почти находится в контроллере, что не очень хорошо т.к идет дубляж кода, и в случае добалвения новых сущностей придется переписывать все. по поводу причем тут ооп - хочу снизить дубляж кода, то есть по факту создать такой сервис, который принимал бы в параметры нужную сущность, и запрос пользователя и возвращал нужный набор данных. Ну и хотелоь быэто все раскидать в нужные сервисы "по красоте"

спрошу тут

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

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

@f3ath ну ты же по-любому знаешь

Тебе ответили чо-нибудь по теме?

а то чет все молчат

обиделись что ли

аа, так ты просто думал

😆

вот это поворот

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

множественное наследование

отсутствие свойств

множественное наследование

у интерфейса свойств типо нету?

ну и обязательность реализации

Ясно

Интересненько

Т.е. по сути создавать интерфейс для одного класса - не имеет смысла?

сложная тема эти интерфейсы

да читал

но проблема таких учебников в том, что там какие-то анрил примеры)

Т.е. по сути создавать интерфейс для одного класса - не имеет смысла?

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

Ну ладно

я кстати тоже как раз читаю

но до этого еще не дошел)

Спасибо

Т.е. по сути создавать интерфейс для одного класса - не имеет смысла?

теоритически если реализация может потом поменятся

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

Тогда интересно, зачем нужен абстрактный класс

ну, в смысле, в С++ то понятно, там нет интерфейсов вроде

вместо них абстрактные классы

очень тонкая грань

абстрактный класс нужен там где есть абстрактные методы

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

интерфейс тоже нельзя создать)

в интерфейсе может быть реализация

(такое можно и в java сделать)

но пока не смотрим на java :D

в интерфейсе может быть реализация

о_О

разве?

ой в абстрактном классе

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

в интерфейсе в java начиная с 8 версии можно фигарить код :D

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

просто думал о java и руки не то написали

разница в том что в случае интерфейсов

один класс может реализовывать несколько интерфейсов

в случае с абстратными классами только один абстрактный класс (один родитель в наследование)

ну опять же кроме C++ :D

ага

короче как обычный класс

можно обычные методы писать даже

в абстрактном классе да

можно даже в обычных методах вызывать абстрактные методы )

Наверное это для каких-то архисложных систем

абстрактный класс ?

Потому что я пока не вижу, где это можно юзать

да