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

прям очень

еще swift кстати

в тс есть опшналы?

в тс есть опшналы?

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

можешь с примером? Это аналог 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 ну ты же по-любому знаешь

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

Вчера тоже об этом думал. ?

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

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

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

Ну, я не думаю что тут есть телепаты, способные читать мои мысли. ?

Спят все наверное.

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

?

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

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

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

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

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

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

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

Ясно

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

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

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

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

Зандстру не читал?

да читал

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

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

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

Я как раз читаю, там вроде всё как надо.

Ну ладно

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

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

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

https://habrahabr.ru/post/30444/

Спасибо

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

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

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

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

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

ERROR: S client not available

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

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

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

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

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

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

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

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

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

о_О

разве?

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

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

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

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

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

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

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

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

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

ага

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

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

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

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

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

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

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

да

неа

скорее interface более гибкий

и в более сложных ситуациях использовать его лучше