Я много думал о дизайне языка и о том, какие элементы были бы необходимы для «идеального» языка программирования, и изучение Google Go привело меня к сомнению во многих других общеизвестных знаниях.
В частности, Go, похоже, обладает всеми интересными преимуществами объектно-ориентированного программирования, фактически не имея структуры объектно-ориентированного языка. Там нет классов, только структуры; нет наследования класса / структуры - только встраивание структуры. Здесь нет ни иерархий, ни родительских классов, ни явных реализаций интерфейса. Вместо этого правила приведения типов основаны на свободной системе, похожей на типизацию утки, так что если структура реализует необходимые элементы «Reader», «Request» или «Encoding», вы можете привести ее и использовать как один.
Есть ли что-то в ООП, реализованном в C ++ и Java и C #, которое по своей природе более способно, более легко обслуживаемо и каким-то более мощным, от чего вам придется отказаться при переходе на язык, такой как Go? От какой выгоды вы должны отказаться, чтобы получить простоту, которую представляет эта новая парадигма?
РЕДАКТИРОВАТЬ
Удалил «устаревший» вопрос, который читатели, казалось, были чрезмерно одержимы и рассержены.
Вопрос состоит в том, что может предложить традиционная объектно-ориентированная парадигма (с иерархиями и тому подобным), которую часто можно увидеть в реализациях на общем языке, которую нельзя сделать так легко в этой более простой модели? Или, другими словами, если бы вы разрабатывали язык сегодня, есть ли причина, по которой вы хотели бы включить концепцию иерархии классов?
Ответы:
Там нет новой парадигмы. Ориентация объекта - это шаблон, который вы используете для написания программ, который даже четко не определен. Различные языки предоставляют различные черты, типичные для объектной ориентации (определение новых типов, инкапсуляция, иерархии типов, полиморфизм, передача сообщений и т. Д.), Но могут не обеспечивать другие. В этих случаях сами программисты должны эмулировать их, если возникнет такая необходимость.
Многие из языков, которые предоставляют эти функции, не имеют аналога концепции класса, например, Javascript и Common Lisp. Реализация, обеспечиваемая Java-подобными языками (на основе классов, с единым наследованием, интерфейсами, диспетчеризацией на основе типов), является лишь одной из возможностей, и не обязательно лучшей.
источник
Проверка типов для структурной системы типов намного сложнее, чем просто проверка наличия базового класса в вашем списке наследования. Виртуальная рассылка становится немного сложнее и, вероятно, менее производительной.
Нет. Пока вы можете сделать программу с точки зрения «объектов, которые делают вещи», а не списка инструкций, или объявленного набора правил, или каскадного ряда функций ... реализация не имеет значения. Аналогично, изменение системы типов не лишает законной силы ни один из общих принципов ОО.
Вы все еще можете работать с базовым типом и не заботиться о его фактическом типе. Вы все еще можете расширять типы, не изменяя их. Вы все еще можете заставить тип делать только одну вещь. Вы все еще можете предоставить мелкозернистые интерфейсы. Вы все еще можете предоставлять абстракции для ваших типов.
Как как язык позволяет это, не имеет значения.
источник
Я думаю, что ваша идея об ООП совсем немного
Выбор типирования (номинативный подтип, структурный подтип или утка - или их комбинация) в значительной степени ортогональн к ООП. Наследование и классы полностью ортогональны ООП. Если вы потратите некоторое время, чтобы поиграть с io, вы увидите это.
Теперь вы можете спросить, какой тип системы «лучше», и какие средства повторного использования и комбинации кода. И попробуйте определить преимущества и недостатки между выбором, сделанным в Simula (а затем и в C ++, Java и C #), и выбором, сделанным в Go. Но это все разные и разные вопросы.
В конечном счете, ООП является очень расплывчатым понятием, и все попытки реализовать его имеют огромное разнообразие вкусов. Но чтобы действительно упростить вещи, я бы сказал, что основная идея ООП состоит в том, чтобы составлять системы подсистем SOLID . Теперь это абсолютно стирает грань с другими парадигмами, но я могу предположить, что именно поэтому в последнее время популярность мультипарадигмных языков возросла, и Google сделал свой собственный шаг в этом с Go.
источник
ООП не устарел.
Как сказала Андреа, было предложено много концепций в качестве альтернативы классам (например, класс типов haskell). У ООП есть одно большое преимущество: его преподают во многих местах, и культура ООП широко распространена среди разработчиков.
Это позволяет более богатое общение внутри команды. О фабриках говорить проще, чем о скигистоморфных препроморфизмах . ООП структурирует способ организации и обмена информацией о вашей программе с помощью часто используемых диаграмм. Это мощный актив.
источник
Нет, здесь нет ничего нового, и ООП не устарел. C ++ также имеет неявные интерфейсы в форме шаблонов, но люди все еще используют виртуальные функции. Вам необходимы явные интерфейсы, например двоичные интерфейсы или интерфейсы, где другой код просто не известен во время компиляции.
Вы могли бы утверждать, что это просто случай умозаключения против его явного указания, что не имеет ничего общего с «новой парадигмой» и на самом деле просто более удобно.
источник