Ну вот пример с Shape, Circle и Rectangle, который обсуждали чуть выше. Добавить Polygon ещё какой-нибудь, чтобы он выглядел более-менее реалистичным. Данные разные, но подсчёт площади приводят как хрестоматийный пример применения полиморфизма
Either на полиморфизме не сделаешь.
Ну как. Допустим метод возвращает объект, который может быть ошибкой или нормальным значением. И надо выполнить один код, если это ошибка и другой, если это значение. Этот метод может принимать дополнительный аргумент, в котором будет объект, реализующий интерфейс с двумя методами. Один метод для действия, которое надо произвести, если случилась ошибка и другой для действия, которое надо сделать с нормальным результатом. Мне кажется вот так можно. Или я неправильно всё понял?
Дизайнеры новых языков программирования. Чем младше язык, тем меньше вероятность, что там будет goto. А если и будет, то совсем не тот, я в языках из прошлого века
В Java он есть, но я не видел чтобы его кто-то использовал.
Он есть, но от того, как его использовали в C осталась только одна маленькая часть - прыжки по циклам. А другого ничего нет. Потому что если бы было, люди бы писали код, который Дийкстра в своё время предложил считать вредным
Shape, Circle и Rectangle с подсчётом площади? Это ж как раз идеальный кейс для ПМ и sealed интерфейсов. Если у нас есть закрытый интерфейс Shape, у которого две реализации Circle и Rectangle, то для подсчёта площади можно сделать один метод, в котором switch с pattern matching и в ветках возвращается площадь, посчитанная по соответствующей формуле.
Это не только производительнее, но ещё и даёт программисту возможность понять, что формулы для посчёта площади круга и прямоугольника по большому счёту не отличаются ничем, кроме коеффициента, который можно хранить в таблице, рядом с этим же методом
Ну только Data Oriented Programming с функциональным программированием имеет примерно столько же общего, сколько с ООП. Рекорды имутабельные, имутабельность, конечно, ключевой компонент ФП, но не ключевой компонент Data Oriented Programming.
То о чём пишет Гётц это традиционный старый добрый процедурный подход. Данные отдельно, код, который их обрабатывает отдельно. Который да, де факто в серверных приложениях сейчас повсюду.
Паттерн матчинг в свитчах провоцирует писать код, который не использует полиморфизм, то есть провоцирует к отходу от парадигмы ООП, вот что я хотел сказать.
Возможно, надо раскрыть, почему я называю ПМ и ООП ортогональными понятиями?
Мне была бы любопытна ваша точка зрения по вопросу, где точно надо использовать ПМ, а где точно надо использовать полиморфизм. Без краевых случаев, а вот где явно то, а где явно другое.
Нет так. Код не знает, какой объект будет на входе, но он знает, что это будет объект одного из перечисленных типов. А при использовании полиморфизма, единственное, что знает код, это что объект реализует какой-то конкретный интерфейс
Так в том куске в котором switch написан, перечислены все типы данных, которые может принимать переменная. То есть они должны быть известны на этапе сборки. А полиморфизм предполагает позднее связывание. Как и вообще ООП по Алану Кею
Simula - это же не методичка и не спецификация ООП.
Так и нет никакой спецификации, есть только доминирующая в Java мире школа, которая декларирует, что ООП это полиморфизм. Но если бы методичка была, то это был бы подход C++, именно так ООП ворвался в мир. Страуструп может не делал утверждений про полиморфизм, я тоже не помню, но не пропустил считчи в язык и я считаю, что это хорошо демонстрирует его точку зрения.
Полиморфизм предполагает, что код даже не подозревает с объектами каких типов работает на самом деле. А тут всё явно. Так что это уже не "полиморфизм без полиморфизма" , а "ООП без полиморфизма"
Заявление "switch с паттерн-матчингом – это и есть ортодоксальное ООП!" сродни по силе чему-нибудь вроде "ключевое слово class – это и есть ортодоксальное ООП!".
Совсем недавно (по геологическим меркам) в джаваскрипте не было ключевого слова класс. Но ООП было, хоть и немного странное. Если бы джаваскрипт был первым популярным языком, в котором появилось ООП, то после добавления ключевого слова класс, многие задались бы вопросом, а не отход ли это от первоначальных идей. И вполне можно было бы сказать, что ключевое слово class – это и есть ортодоксальное ООП. Сославшись на древний, но в этой альтернативной вселенной не "взлетевший" С++.
Проблема, которую решают и полиморфизм ("ортодоксальное ООП"), и switch по типу, - это обработка разнородных данных. Но они решают ее с противоположных сторон
Ну и вот годами нам говорят, что решать обработку разнородных данных без полиморфизма это принципиальное нарушение ООП. А тут оказывается, что люди которые его создавали прямо сразу именно так и хотели писать код. И не видели в этом ничего страшного.
Возвращение switch-case в современной Java - не столько возвращение к "ортодоксальному ООП", сколько признание, что оба подхода имеют право на жизнь.
Да, но очень неожиданно, что это именно вовзращение первоначальной идеи, а не новьё, утащенное из Котлина со Скалой ))
@MockBean на все классы, которые ходят по ресту, в родительском классе.
Я тоже периодически так делаю, но мне постоянно высказывают, что это неправильно и что на самом деле надо мокать сетевые вызовы с помощью Wiremock. А я повторяю, что не вижу ничего страшного в том, чтобы просто замокать сервис. Если сервис неудобно мокать (так бывает, например с фейн клиентами), то сделать под него обёртку и замокать уже её ))
Не придумал пока что, что делать, когда реально нужен @MockBean.
Вот я прямо не знаю. Я выношу все @MockBean в родительский класс (вот как во втором пункте) и как правило мокаю только то, что придётся мокать. То есть то что ходит во внешние сервисы и то, что возвращает настройки. А ситуаций, где нужен полноценный мок для полноценной бизнес-логики... В интеграционных тестах стараюсь избегать. Для этого стараюсь писать юнит тесты (в узком смысле этого выражения) с использованием Мокито
Ну вот вопрос рассчётов он какой-то совсем мутный. Есть у меня какой-то RPS допустим. И дальше надо думать, как его обеспечить. И вот как? Для обеспечения 1000 RPS надо испльзовать какую-то базу данных? Но она же на разных железках может работать, с разным количеством памяти. Почём мне знать, сколько запросов в секунду она мне обеспечит?
Типа взять систему, потом подать на неё нагруку и посмотреть, справляется ли, тут понятно всё. Но заранее как я это пойму?
Ну вот пример с Shape, Circle и Rectangle, который обсуждали чуть выше. Добавить Polygon ещё какой-нибудь, чтобы он выглядел более-менее реалистичным. Данные разные, но подсчёт площади приводят как хрестоматийный пример применения полиморфизма
Ну как. Допустим метод возвращает объект, который может быть ошибкой или нормальным значением. И надо выполнить один код, если это ошибка и другой, если это значение. Этот метод может принимать дополнительный аргумент, в котором будет объект, реализующий интерфейс с двумя методами. Один метод для действия, которое надо произвести, если случилась ошибка и другой для действия, которое надо сделать с нормальным результатом. Мне кажется вот так можно. Или я неправильно всё понял?
Дизайнеры новых языков программирования. Чем младше язык, тем меньше вероятность, что там будет goto. А если и будет, то совсем не тот, я в языках из прошлого века
Он есть, но от того, как его использовали в C осталась только одна маленькая часть - прыжки по циклам. А другого ничего нет. Потому что если бы было, люди бы писали код, который Дийкстра в своё время предложил считать вредным
Shape, Circle и Rectangle с подсчётом площади? Это ж как раз идеальный кейс для ПМ и sealed интерфейсов. Если у нас есть закрытый интерфейс Shape, у которого две реализации Circle и Rectangle, то для подсчёта площади можно сделать один метод, в котором switch с pattern matching и в ветках возвращается площадь, посчитанная по соответствующей формуле.
Это не только производительнее, но ещё и даёт программисту возможность понять, что формулы для посчёта площади круга и прямоугольника по большому счёту не отличаются ничем, кроме коеффициента, который можно хранить в таблице, рядом с этим же методом
А эталонный пример для полиморфизма?
Ну только Data Oriented Programming с функциональным программированием имеет примерно столько же общего, сколько с ООП. Рекорды имутабельные, имутабельность, конечно, ключевой компонент ФП, но не ключевой компонент Data Oriented Programming.
То о чём пишет Гётц это традиционный старый добрый процедурный подход. Данные отдельно, код, который их обрабатывает отдельно. Который да, де факто в серверных приложениях сейчас повсюду.
Собственно поэтому его и убрали
Паттерн матчинг в свитчах провоцирует писать код, который не использует полиморфизм, то есть провоцирует к отходу от парадигмы ООП, вот что я хотел сказать.
Мне была бы любопытна ваша точка зрения по вопросу, где точно надо использовать ПМ, а где точно надо использовать полиморфизм. Без краевых случаев, а вот где явно то, а где явно другое.
Нет так. Код не знает, какой объект будет на входе, но он знает, что это будет объект одного из перечисленных типов. А при использовании полиморфизма, единственное, что знает код, это что объект реализует какой-то конкретный интерфейс
Так в том куске в котором switch написан, перечислены все типы данных, которые может принимать переменная. То есть они должны быть известны на этапе сборки. А полиморфизм предполагает позднее связывание. Как и вообще ООП по Алану Кею
Так и нет никакой спецификации, есть только доминирующая в Java мире школа, которая декларирует, что ООП это полиморфизм. Но если бы методичка была, то это был бы подход C++, именно так ООП ворвался в мир. Страуструп может не делал утверждений про полиморфизм, я тоже не помню, но не пропустил считчи в язык и я считаю, что это хорошо демонстрирует его точку зрения.
А вот Мартин статью написал, я кстати переводил. Вот она https://habr.com/ru/articles/474518/
Если бы не моя ненависть к диалектике, я бы сказал, что это очередной виток Гегелевкой спирали, звучит красиво ))
Полиморфизм предполагает, что код даже не подозревает с объектами каких типов работает на самом деле. А тут всё явно. Так что это уже не "полиморфизм без полиморфизма" , а "ООП без полиморфизма"
Совсем недавно (по геологическим меркам) в джаваскрипте не было ключевого слова класс. Но ООП было, хоть и немного странное. Если бы джаваскрипт был первым популярным языком, в котором появилось ООП, то после добавления ключевого слова класс, многие задались бы вопросом, а не отход ли это от первоначальных идей. И вполне можно было бы сказать, что ключевое слово class – это и есть ортодоксальное ООП. Сославшись на древний, но в этой альтернативной вселенной не "взлетевший" С++.
Ну и вот годами нам говорят, что решать обработку разнородных данных без полиморфизма это принципиальное нарушение ООП. А тут оказывается, что люди которые его создавали прямо сразу именно так и хотели писать код. И не видели в этом ничего страшного.
Да, но очень неожиданно, что это именно вовзращение первоначальной идеи, а не новьё, утащенное из Котлина со Скалой ))
Вот, собственно, об этом я и говорю. Класс должен иметь только одну причину для изменения
S это single reason to change
А большинство, да, понимает как сингл респонсибилити
А как тогда тестировать логику связанную со спрингом? Ну и впринципе как писать интеграционные тесты тогда?
Я тоже периодически так делаю, но мне постоянно высказывают, что это неправильно и что на самом деле надо мокать сетевые вызовы с помощью Wiremock. А я повторяю, что не вижу ничего страшного в том, чтобы просто замокать сервис. Если сервис неудобно мокать (так бывает, например с фейн клиентами), то сделать под него обёртку и замокать уже её ))
Вот я прямо не знаю. Я выношу все
@MockBeanв родительский класс (вот как во втором пункте) и как правило мокаю только то, что придётся мокать. То есть то что ходит во внешние сервисы и то, что возвращает настройки. А ситуаций, где нужен полноценный мок для полноценной бизнес-логики... В интеграционных тестах стараюсь избегать. Для этого стараюсь писать юнит тесты (в узком смысле этого выражения) с использованием МокитоНу вот вопрос рассчётов он какой-то совсем мутный. Есть у меня какой-то RPS допустим. И дальше надо думать, как его обеспечить. И вот как? Для обеспечения 1000 RPS надо испльзовать какую-то базу данных? Но она же на разных железках может работать, с разным количеством памяти. Почём мне знать, сколько запросов в секунду она мне обеспечит?
Типа взять систему, потом подать на неё нагруку и посмотреть, справляется ли, тут понятно всё. Но заранее как я это пойму?
Вы просто написали про интернет мемность, а в интернет мемах это слово имеет вообще другое значение ))
Так всё-таки, что означает словосочетание "супер-базированная книга"?
Если так, то получается, что опытный разработчик на собеседование попасть не сможет