Только если это безопасно и вычисляется на этапе компиляции. Он может не использовать виртуальный вызов для точно известного на момент вызова типа и его метода. Но в примере выше так не будет, так как я как разработчик привёл значение к ссылке на общий объект.
Если отправка события некоему объекту это синхронное действо, то разницы никакой нет, кроме того, каким словом это называть. А вот если отправка события летит в очередь, то это уже совсем-совсем другое дело.
В любом мало-мальском современном ЯП можно использовать такой подход, но удовольствия в этом мало, если применять вообще везде. Такое нужно применять когда в этом есть необходимость. Например, для распределённых вычислений, берём Akka или Orleans. Для стримов берём кафку, если синхронный реквест/реплай нужен, то городим огород на AMQP или берём Nats. Ну а если это монолит, то очереди в памяти, в гошке те же ченнелы.
Я хочу сказать, что мы ничего не лишились. Вы описываете один из тех случаев, когда подход строится по принципу "всё есть....": всё есть объект, все структуры и переменные неизменны, все взаимодействия это события, всё есть функция с каррированием. Конечно это даёт определённые преимущества, например, для параллелизма, но и в то же время награждает существенными болезненными ограничениями, где казалось бы простые вещи приходится городить костылями.
Мне по душе мульти-парадигменный подход, который даёт возможность выбирать наиболее подходящие паттерны под задачу.
"Извне" работает только если программист реализует компонент, который используется другими программистами, при реализации логики. А зачастую это компонент, который уже зацеплен к презентации, не будет это использовать другой программист, это конечная логика для пользователя. Т.е. это JSON для фронта, или отображаемая форма с контролами, или HTML.
Договор это зафиксированные юридически отношения с кастомером, в котором прописывается комплекс услуг, товаров, физических действий, осуществляемых в реальности, и только часть из них фиксируется в информационной системе.
И когда пытаются создать класс "Договор" или "Клиент", и описать в нём методы 1 в 1 соответствующие реальности, это не работает просто из-за нарушения понятий.
В информационной системе "Договор" это запись, отображающая какую-то часть бизнеса в реальном мере, а точнее какие-то аспекты этого состояния. И мы работаем с состоянием, а не с сами договором. Мы не можем "Подписать" договор в системе, мы можем изменить статус с "Не подписано" на "Подписано" в его состоянии. Поэтому метод "Подписать" в классе это искажение реальности. Новички об это часто спотыкаются, и некоторые с завидным упорством пытаются смоделировать реальный мир в классе. Получается это плохо, и, самое главное, инфраструктура, синтаксис языка, особенности используемого фреймворка смешиваются с терминологией бизнеса. И получается каша, которую сопровождать потом сложно.
Не знаком к сожалению с синтаксисом D. Вижу тут выведение типа через auto, нет объекта как такового, это структура и компилятор явно вызывает известные на момент компиляции методы применительно к конкретной структуре известного типа, поэтому это работает на стеке. А давайте в общий базовый тип и вызовем метод, общий для всех объектов. Получится?
Пример на C#
object v = 42;
// вызов метода общего для всех-всех объектов
Console.WriteLine(v.ToString()); // выведет: 42
Компилятор "не знает" чей ToString() я вызываю, в рантайме вызывается метод, вычисляемый для конкретного экземпляра, через vtable.
Ну например, если в общих чертах, то физический реальный договор это не тоже самое, что запись в БД. Под действием "подписать" может пониматься, проставить в записи о договоре отметку, что клиент собственноручно расписался на обоих бумажных экземплярах, и приложить фотографию. Т.е. мы говорит про изменение состояние записи в приложении, которое отвечает за какой-то аспект договорных отношений. Нет никакого "договора" в приложении. Есть запись, отражающая информационное состояние. И как показала моя практика (в различных проектных командах), это создаёт у разработчиков путаницу в определениях и сложному и совершенно не нужному дизайну классов. Там где нам надо было управлять состоянием, мы пытаемся вести себя как объекты реального мира, имитировать их. Это приводит к тому, что мы пытаемся контролировать на уровне класса, что контролировать там не нужно. Например, то же самое подписание, это с точки зрения бизнеса атомарное действия, либо подписал, либо нет, а с точки зрения операционного учёта, это транзакция с комплексом событий, оркестрация всего этого добра с подтверждениями и согласования между разными системами.
Ну далеко не только в Java же. Но везде есть свои, как говорится, приколы.
Про посылку сообщений объекту, ну это как бы тоже уровень абстракции. Чем строчка с вызовом метода у объекта по его ссылке не "отправка сообщения"? Если метод виртуальный, или вообще ЯП динамический, то в ответ также получим либо исключение, либо какой-нибудь undefined. Почему от абстракции посылки сообщений вообще везде ушли, наверное потому что это дико неудобно и сложно. Но также, не ручаюсь за именно такое объяснение. Однако имеем что имеем. На языках ООП, написаны горы полезных продуктов, в том числе те, которыми мы ежедневно пользуемся.
Стоит всё же кое что добавить к сказанному. Споры вокруг ООП чаще всего напоминают спор глухого со слепым. Огромный пласт работы, в которой задействованы программисты, это императивная логика, построенная на вызове методов, аннотациях и условиях, а классы это 99% контейнеры данных, контейнеры логики (контроллеры например), просто наборы методов для внедрения в DI. Нет тут никакой потребности в инкапсуляции, что и от кого скрывать? Это верхнеуровневая логика, прямо за ней уже находится пользователь, а не другой программист. Код призван решать конкретную бизнес задачу. Он типовой, похож на копипасту, но для бизнеса он крайне важен, так как закрывает таску в джире и открывает новую фичу. В этих условиях нужно понять разработчика, ему этот ООП как филькина грамота. Даёшь функциональщину! Вот это дело. Паттерн матчинги, лямбды, вот это всё нужно. А ваши ООП, это для дедов :)
Всё зависит от применения. Прикладная логика редко требует разработки классов. В основном это чистый императив и DTO. На этой почве чаще всего и звучат "ООП нинужен", когда основная часть работы это перекладывание данных из JSON в DTO и запросы в БД. При чём на плечах огромной кучи библиотек и платформы, с кучей классов под капотом. По той же логике можно с уверенностью сказать, что микроэлектронника не нужна. Да, у меня есть телефон, куча аппаратуры, я просто кнопки жму, зачем мне нужна ваша микроэлектронника? :)
Из своего опыта, когда начал разрабатывать библиотеки, свои расширения платформы, а потом и платформу, то все возможности ООП в такой разработке используются на 100%. И всё это очень нужно.
Утверждения про "побеждает", это примерно как щупать в слепую слона за хобот и утверждать, что хобот, это всё что нужно, хобот победил :)
Почему не норм? Это одна из эффективных форм познания. Сначала делаем глобальное обобщение, потом находим нарушения и несоответствия. Или надо сразу всё знать и говорить всегда только правильные вещи, и не дай бог ошибиться?
Нельзя стать экспертом, не пытаясь им стать. Или как должно быть. 30 лет программируешь, а потом просыпаешься и понимаешь, вот теперь кажется я и стал экспертом, теперь мне можно писать на хабр, и меня не заклюют и не заклеймят новичком :)
А если назначение было переосмыслено? Сколько вещей в мире было создано с одним назначением, а оказалось, что для этого оно подходит плохо, но зато хорошо подходит для другого? В разработке это наблюдается сплошь и рядом. А без холиворов не будет переосмысления, конечно имеются в виду аргументированные холиворы, а не набрасывание на вентилятор.
Вот самый банальный пример: "всё есть объект". Попытка глобального обобщения разбивается о суровую реальность. Когда "всё объект", технически это приводит к необходимости вот это "всё" держать в куче, чтобы была ссылка на объект. Но это не всегда рационально, местами крайне избыточно и сильно бьёт по производительности. И начинаются пляски, ну ладно "не всё объект" или по крайней мере не всегда, давайте вот отдельно выделим примитивы (Java), или объекты-структуры (ValueType, C#).
ООП не просто инструмент в вакууме. Это инструмент, который позволяет снизить сложность большого спектра задач. Но когда с помощью ООП начинают моделировать объекты реального мира, от банальных "кошек/собак" с их реализацией "мяукать/гавкать", до более сложных "договор" с методами "подписать", "принять", "отклонить" — то очень быстро приходит понимание, что ООП с этим справляется просто отвратительно и в целом для этого не подходит. Если конечно, находясь под эйфорией, не начинать подгонять молотком и зубилом любую задачу под ООП. Вот здесь самая суть проблемы, которую и превратили во зло.
В наборе тезисов есть недосказанность. Основное, классическое, и корневое заблуждение — это использование ООП, как описание объектов реального мира. ООП это поведение, которое имеет изменяемое или не изменяемое состояние, с возможностью инкапсуляции. Это не "кошки" и "собаки", которые могут "мяукать" или "гавкать". Вот такие примеры, призванные объяснить новичку сам принцип, превратились в примеры для подражания. А затем, спустя какое-то время, новичок сталкивается с тем, что ООП совершенно не подходит для описания объектов реального мира, и становится злом.
На голанг своя специфика, на прикладном уровне думать приходится только о структуре, логике. О производительности, потоках, и прочих узкоспециализированных концепциях задумываться приходиться редко. Благодаря маленьким масштабам, компактным сборкам, это всё бодро скейлится.
На пыхе, если оставаться в парадигме выполнил задачу => умер, то совсем не надо париться ни о чём. Только не надо сувать PHP между другими приложениями, в интеграционный слой. Там ему плохо, узко, тесно и ваще.
Так он и не задушил в описываемый период. А вот была JIT и ngen, который, генерил скомпиленные в *.ni.dll файлики. Да, компьютеры были медленными, именно поэтому в полный рост скрипты, расцвет PHP, всяких перлов и прочего.
Только если это безопасно и вычисляется на этапе компиляции. Он может не использовать виртуальный вызов для точно известного на момент вызова типа и его метода. Но в примере выше так не будет, так как я как разработчик привёл значение к ссылке на общий объект.
Если отправка события некоему объекту это синхронное действо, то разницы никакой нет, кроме того, каким словом это называть. А вот если отправка события летит в очередь, то это уже совсем-совсем другое дело.
В любом мало-мальском современном ЯП можно использовать такой подход, но удовольствия в этом мало, если применять вообще везде. Такое нужно применять когда в этом есть необходимость. Например, для распределённых вычислений, берём Akka или Orleans. Для стримов берём кафку, если синхронный реквест/реплай нужен, то городим огород на AMQP или берём Nats. Ну а если это монолит, то очереди в памяти, в гошке те же ченнелы.
Я хочу сказать, что мы ничего не лишились. Вы описываете один из тех случаев, когда подход строится по принципу "всё есть....": всё есть объект, все структуры и переменные неизменны, все взаимодействия это события, всё есть функция с каррированием. Конечно это даёт определённые преимущества, например, для параллелизма, но и в то же время награждает существенными болезненными ограничениями, где казалось бы простые вещи приходится городить костылями.
Мне по душе мульти-парадигменный подход, который даёт возможность выбирать наиболее подходящие паттерны под задачу.
"Извне" работает только если программист реализует компонент, который используется другими программистами, при реализации логики. А зачастую это компонент, который уже зацеплен к презентации, не будет это использовать другой программист, это конечная логика для пользователя. Т.е. это JSON для фронта, или отображаемая форма с контролами, или HTML.
Договор это зафиксированные юридически отношения с кастомером, в котором прописывается комплекс услуг, товаров, физических действий, осуществляемых в реальности, и только часть из них фиксируется в информационной системе.
И когда пытаются создать класс "Договор" или "Клиент", и описать в нём методы 1 в 1 соответствующие реальности, это не работает просто из-за нарушения понятий.
В информационной системе "Договор" это запись, отображающая какую-то часть бизнеса в реальном мере, а точнее какие-то аспекты этого состояния. И мы работаем с состоянием, а не с сами договором. Мы не можем "Подписать" договор в системе, мы можем изменить статус с "Не подписано" на "Подписано" в его состоянии. Поэтому метод "Подписать" в классе это искажение реальности. Новички об это часто спотыкаются, и некоторые с завидным упорством пытаются смоделировать реальный мир в классе. Получается это плохо, и, самое главное, инфраструктура, синтаксис языка, особенности используемого фреймворка смешиваются с терминологией бизнеса. И получается каша, которую сопровождать потом сложно.
Не знаком к сожалению с синтаксисом D. Вижу тут выведение типа через
auto, нет объекта как такового, это структура и компилятор явно вызывает известные на момент компиляции методы применительно к конкретной структуре известного типа, поэтому это работает на стеке. А давайте в общий базовый тип и вызовем метод, общий для всех объектов. Получится?Пример на C#
Компилятор "не знает" чей
ToString()я вызываю, в рантайме вызывается метод, вычисляемый для конкретного экземпляра, через vtable.Если я не пользуюсь самолётами, а езжу только поездами, можно ли считать, что в моём мире не существует самолётов?
Согласен, для формошлёпства и перекладывания из DTO в JSON, ООП не нужен, всё это от лукавого.
Ну например, если в общих чертах, то физический реальный договор это не тоже самое, что запись в БД. Под действием "подписать" может пониматься, проставить в записи о договоре отметку, что клиент собственноручно расписался на обоих бумажных экземплярах, и приложить фотографию. Т.е. мы говорит про изменение состояние записи в приложении, которое отвечает за какой-то аспект договорных отношений. Нет никакого "договора" в приложении. Есть запись, отражающая информационное состояние. И как показала моя практика (в различных проектных командах), это создаёт у разработчиков путаницу в определениях и сложному и совершенно не нужному дизайну классов. Там где нам надо было управлять состоянием, мы пытаемся вести себя как объекты реального мира, имитировать их. Это приводит к тому, что мы пытаемся контролировать на уровне класса, что контролировать там не нужно. Например, то же самое подписание, это с точки зрения бизнеса атомарное действия, либо подписал, либо нет, а с точки зрения операционного учёта, это транзакция с комплексом событий, оркестрация всего этого добра с подтверждениями и согласования между разными системами.
Хах :) Вопрос с подвохом.
Ну далеко не только в Java же. Но везде есть свои, как говорится, приколы.
Про посылку сообщений объекту, ну это как бы тоже уровень абстракции. Чем строчка с вызовом метода у объекта по его ссылке не "отправка сообщения"? Если метод виртуальный, или вообще ЯП динамический, то в ответ также получим либо исключение, либо какой-нибудь
undefined. Почему от абстракции посылки сообщений вообще везде ушли, наверное потому что это дико неудобно и сложно. Но также, не ручаюсь за именно такое объяснение. Однако имеем что имеем. На языках ООП, написаны горы полезных продуктов, в том числе те, которыми мы ежедневно пользуемся.Стоит всё же кое что добавить к сказанному. Споры вокруг ООП чаще всего напоминают спор глухого со слепым. Огромный пласт работы, в которой задействованы программисты, это императивная логика, построенная на вызове методов, аннотациях и условиях, а классы это 99% контейнеры данных, контейнеры логики (контроллеры например), просто наборы методов для внедрения в DI. Нет тут никакой потребности в инкапсуляции, что и от кого скрывать? Это верхнеуровневая логика, прямо за ней уже находится пользователь, а не другой программист. Код призван решать конкретную бизнес задачу. Он типовой, похож на копипасту, но для бизнеса он крайне важен, так как закрывает таску в джире и открывает новую фичу. В этих условиях нужно понять разработчика, ему этот ООП как филькина грамота. Даёшь функциональщину! Вот это дело. Паттерн матчинги, лямбды, вот это всё нужно. А ваши ООП, это для дедов :)
Всё зависит от применения. Прикладная логика редко требует разработки классов. В основном это чистый императив и DTO. На этой почве чаще всего и звучат "ООП нинужен", когда основная часть работы это перекладывание данных из JSON в DTO и запросы в БД. При чём на плечах огромной кучи библиотек и платформы, с кучей классов под капотом. По той же логике можно с уверенностью сказать, что микроэлектронника не нужна. Да, у меня есть телефон, куча аппаратуры, я просто кнопки жму, зачем мне нужна ваша микроэлектронника? :)
Из своего опыта, когда начал разрабатывать библиотеки, свои расширения платформы, а потом и платформу, то все возможности ООП в такой разработке используются на 100%. И всё это очень нужно.
Утверждения про "побеждает", это примерно как щупать в слепую слона за хобот и утверждать, что хобот, это всё что нужно, хобот победил :)
Классика :)
Почему не норм? Это одна из эффективных форм познания. Сначала делаем глобальное обобщение, потом находим нарушения и несоответствия. Или надо сразу всё знать и говорить всегда только правильные вещи, и не дай бог ошибиться?
Нельзя стать экспертом, не пытаясь им стать. Или как должно быть. 30 лет программируешь, а потом просыпаешься и понимаешь, вот теперь кажется я и стал экспертом, теперь мне можно писать на хабр, и меня не заклюют и не заклеймят новичком :)
А если назначение было переосмыслено? Сколько вещей в мире было создано с одним назначением, а оказалось, что для этого оно подходит плохо, но зато хорошо подходит для другого? В разработке это наблюдается сплошь и рядом. А без холиворов не будет переосмысления, конечно имеются в виду аргументированные холиворы, а не набрасывание на вентилятор.
Вот самый банальный пример: "всё есть объект". Попытка глобального обобщения разбивается о суровую реальность. Когда "всё объект", технически это приводит к необходимости вот это "всё" держать в куче, чтобы была ссылка на объект. Но это не всегда рационально, местами крайне избыточно и сильно бьёт по производительности. И начинаются пляски, ну ладно "не всё объект" или по крайней мере не всегда, давайте вот отдельно выделим примитивы (Java), или объекты-структуры (ValueType, C#).
ООП не просто инструмент в вакууме. Это инструмент, который позволяет снизить сложность большого спектра задач. Но когда с помощью ООП начинают моделировать объекты реального мира, от банальных "кошек/собак" с их реализацией "мяукать/гавкать", до более сложных "договор" с методами "подписать", "принять", "отклонить" — то очень быстро приходит понимание, что ООП с этим справляется просто отвратительно и в целом для этого не подходит. Если конечно, находясь под эйфорией, не начинать подгонять молотком и зубилом любую задачу под ООП. Вот здесь самая суть проблемы, которую и превратили во зло.
В наборе тезисов есть недосказанность. Основное, классическое, и корневое заблуждение — это использование ООП, как описание объектов реального мира. ООП это поведение, которое имеет изменяемое или не изменяемое состояние, с возможностью инкапсуляции. Это не "кошки" и "собаки", которые могут "мяукать" или "гавкать". Вот такие примеры, призванные объяснить новичку сам принцип, превратились в примеры для подражания. А затем, спустя какое-то время, новичок сталкивается с тем, что ООП совершенно не подходит для описания объектов реального мира, и становится злом.
На голанг своя специфика, на прикладном уровне думать приходится только о структуре, логике. О производительности, потоках, и прочих узкоспециализированных концепциях задумываться приходиться редко. Благодаря маленьким масштабам, компактным сборкам, это всё бодро скейлится.
На пыхе, если оставаться в парадигме выполнил задачу => умер, то совсем не надо париться ни о чём. Только не надо сувать PHP между другими приложениями, в интеграционный слой. Там ему плохо, узко, тесно и ваще.
Так он и не задушил в описываемый период. А вот была JIT и ngen, который, генерил скомпиленные в *.ni.dll файлики. Да, компьютеры были медленными, именно поэтому в полный рост скрипты, расцвет PHP, всяких перлов и прочего.