Ты пользуешься одной из топовых систем типов(flow), не все так могут)

Топовых production ready конечно же

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

Ты пользуешься одной из топовых систем типов(flow), не все так могут)

Ну лан ?

Но типа да, к этому стоит стремиться)

Ребята, применяется ли в русском языке слово специализация, в значении сужение типа? Вроде как да(например когда школьники в старших классах выбирают специализацию подразумевается сужение их обучения). Но что то мне кажется звучит неказисто. Geometrically, a square is a specialisation of a rectangle: every square is a rectangle, not every rectangle is a square. Как вот тут заменить слова специализация?

подвид?

частный случай?

Не использовать термины на русском языке

Серьезно, просто забудьте

а если надо бабушке объяснить?

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

Теория типов настолько неинтуитивна местами, что просто мозг клинит, добавлять в винегрет из inheritance / variance / soundess / subtyping ещё и переводы с одного языка на другой — это довольно отчаяно

Обучать школьников неправильным терминам вообще не круто, например. Неправильным, потому что русские слова несут с собой дополнительные, неверные в данной области, смыслы. Это просто обман, чтобы набрать классы

Хорошие новости — так как все варианты одинаково плохие, то можно выбирать любой)

Наткнулся на картинку. Чувак позиционирует это как луковую архитектуру...я не понял почему аппликешйн снаружи инфраструктуры??

я не очень уверен в большой ценности такого разбиения)

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

что значит могут передвигаться?)) Тут же показывается зависимость верних слоев от внутренних

тут получается что у нас аппликейшн слой зависит от базы данных или от того откуда пришел запрос из консоли или из очереди)

Кек, доменная модель - через интерфейсы зависит от инфраструктуры - такое то ООП, потом без моков никуда

что значит зависит? Это интерфейсы доменные реализуются в инфраструткурном слое же, домен о них не знает ничего

а с такой логикой можно вывести и зависимость доменной модели от железа на сервере или вообще от электричества

а сетевое взаимодействие — оффтоп? как я понимаю, есть два подхода к (де-)сериализации объектов. хранить опкод и враппер. вот как правильно называются эти подходы, чтобы про плюсы-минусы почитать

что значит могут передвигаться?)) Тут же показывается зависимость верних слоев от внутренних

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

Так. А если в интерфейсе свойство ридонли, а в реализующем его классе — мутабельное, это нормально?

Так. А если в интерфейсе свойство ридонли, а в реализующем его классе — мутабельное, это нормально?

Да.

Интерфейс же показывает что можно делать, а не то, что нельзя.

Иначе реализация нескольких интерфейсов бы не работала.

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

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

мы про пых или про джаву?

в пыхе все плохо, в джаве тебе и возможность дефолтной реализации методов в интерфейсах, и final для полей...

Я просто абстрактно рассуждаю

ну вообще да - с точки зрения LSP protected филды это зашквар

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

Если не надо модифицировать, то передавай интерфейс, проблема в чём?

Если не надо модифицировать, то передавай интерфейс, проблема в чём?

Так интерфейс и будет всегда перелаваться

Если не надо модифицировать, то передавай интерфейс, проблема в чём?

"передавать интерфейс" нельзя - его можно только принимать

"передавать интерфейс" нельзя - его можно только принимать

Да, принимай интерфейс.

Спасибо за поправку.

Чтобы клиент не парился о реализации, вроде они для этого и нужны же

Да, принимай интерфейс.

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

Так. А если в интерфейсе свойство ридонли, а в реализующем его классе — мутабельное, это нормально?

если флоу ругается, значит нельзя

и еще раз - причем тут "надо модифицировать" - кому надо? что модифицировать?

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

Да. Ты говоришь, что мне нужна вещь, у которой это поле можно читать. И пляши от этого.

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

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

++

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

как-то так да

если есть возможность рид онли штуки на уровне интерфейса описать - как например в c# то все ок: interface ISomething { string Test { get; } }

Да. Ты говоришь, что мне нужна вещь, у которой это поле можно читать. И пляши от этого.

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

ладно не буду на php сегодня накидывать

Вопрос можно так поставить - входит ли иммутабельность в контракт интерфейса или нет

Вопрос можно так поставить - входит ли иммутабельность в контракт интерфейса или нет

Если вводит, то это хреново, имхо.

В пыхе нет средств для этого например, но я не знаю может где-то и есть

Если вводит, то это хреново, имхо.

А что плохого? Лишние опцилнальные ограничения никогда не лишние

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

ERROR: S client not available

А что плохого? Лишние опцилнальные ограничения никогда не лишние

Кстати, readonly, что было вначале, и иммутабельность - немного разные вещи) Иммутабельность можно статически проверить?)

Хм точно, но там получается противоречие в вопросе

Если в языке есть специальный флаг указывающий что свойство нельзя менять то можно

Так. А если в интерфейсе свойство ридонли, а в реализующем его классе — мутабельное, это нормально?

Идеально

ыы

Кстати, readonly, что было вначале, и иммутабельность - немного разные вещи) Иммутабельность можно статически проверить?)

Можно же, не?

Можно же, не?

Как?

Как?

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

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

Ну, если разрешить мутабельность в конструкторе, то наверное да.

Да зачем в конструкторе

Можно ж просто иметь функцию, которая возвращает объект уже нужного типа

Т.е. не совсем конструктор

Можно ж просто иметь функцию, которая возвращает объект уже нужного типа

А это не конструктор?)

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

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

Ок, конструирующая функция.

Фабрикой ее еще назови:/

лол

Эм... Ты как объект создавать без функции, которую можно конструктором назвать, собираешься?

Функцией, которую я не буду называть конструктором

Шах и мат

Эм... Ты как объект создавать без функции, которую можно конструктором назвать, собираешься?

назови инициализатором

Функцией, которую я не буду называть конструктором

Нуок, суть не изменится.

приветы

ооо, моя любимая тема

Ну, если разрешить мутабельность в конструкторе, то наверное да.

Что такое мутабельность? Первый раз такое слово слышу

Для меня ООП – это модульность с разделением по ответственностям. Со слабосвязанным общением друг с другом. А там хоть классы, хоть процедуры, хоть ассемблер, хоть умные унитазы.

Solid тогда

Что такое мутабельность? Первый раз такое слово слышу

Потенциальная возможность изменения чего либо