Преимущества классического ООП над языком Go-like

13

Я много думал о дизайне языка и о том, какие элементы были бы необходимы для «идеального» языка программирования, и изучение Google Go привело меня к сомнению во многих других общеизвестных знаниях.

В частности, Go, похоже, обладает всеми интересными преимуществами объектно-ориентированного программирования, фактически не имея структуры объектно-ориентированного языка. Там нет классов, только структуры; нет наследования класса / структуры - только встраивание структуры. Здесь нет ни иерархий, ни родительских классов, ни явных реализаций интерфейса. Вместо этого правила приведения типов основаны на свободной системе, похожей на типизацию утки, так что если структура реализует необходимые элементы «Reader», «Request» или «Encoding», вы можете привести ее и использовать как один.

Есть ли что-то в ООП, реализованном в C ++ и Java и C #, которое по своей природе более способно, более легко обслуживаемо и каким-то более мощным, от чего вам придется отказаться при переходе на язык, такой как Go? От какой выгоды вы должны отказаться, чтобы получить простоту, которую представляет эта новая парадигма?

РЕДАКТИРОВАТЬ
Удалил «устаревший» вопрос, который читатели, казалось, были чрезмерно одержимы и рассержены.

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

— tylerl
источник

1

ООП сделал процедурное программирование устаревшим? Я ненавижу звучать педантично или что я говорю с тобой, но это было первое предложение, которое пришло в голову. Go предоставляет новую (ish) парадигму. Экспериментируя, пользователи узнают, что у него хорошо, а что нет (как со всеми парадигмами и языками), и в итоге мы получим сотни отличных продуктов (вместе с их долей плохих продуктов), написанных на Go. , По крайней мере, это мое мнение

— Джейми Тейлор

1

Есть некоторые интересные чтения, когда ваш Google для ООП мертв . Я рекомендую Сеть умрет, когда ООП умрет

— Andomar

В ООП есть такая небольшая ценность, что она не стоит тратить ваше время вообще.

— SK-logic

1

Я согласен с предыдущим комментарием, не обращайте слишком много внимания на ООП. Кроме того, ООП не означает C ++ или Java. Попробуйте прочитать abit на ltu.org

— AndreasScheinert

C ++, Java и C # не являются «классическими» языками ООП. Если есть классический язык ООП, я думаю, что это Smalltalk.

— Кевин Клайн

16

Там нет новой парадигмы. Ориентация объекта - это шаблон, который вы используете для написания программ, который даже четко не определен. Различные языки предоставляют различные черты, типичные для объектной ориентации (определение новых типов, инкапсуляция, иерархии типов, полиморфизм, передача сообщений и т. Д.), Но могут не обеспечивать другие. В этих случаях сами программисты должны эмулировать их, если возникнет такая необходимость.

Многие из языков, которые предоставляют эти функции, не имеют аналога концепции класса, например, Javascript и Common Lisp. Реализация, обеспечиваемая Java-подобными языками (на основе классов, с единым наследованием, интерфейсами, диспетчеризацией на основе типов), является лишь одной из возможностей, и не обязательно лучшей.

— Andrea
источник

11

+1 за "не обязательно лучший". Цитируя Алана Кея: «Я изобрел термин« объектно-ориентированный », и могу сказать, что я не имел в виду C ++». (у меня не было C # и / или Java, я бы смиренно догадался)

— herby

1

@ Херби, я видел, это указывало на то, что агентские системы (подобно тому, как работает Эрланг) ближе к возможному намерению Алана Кея для ООП.

— CodexArcanum

2

У Common Lisp определенно есть классы. Но, как правило, класс CL содержит данные, а методы определены в «универсальных функциях». Как побочный эффект, это дает вам удобный способ сделать многократную диспетчеризацию, так как методы больше не тесно связаны с "единственным классом реализации".

— Ватин

Да, я имел в виду, что у него нет классов в смысле Java

— Андреа

5

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

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

Является ли такая система устаревшей концепцией ООП?

Нет. Пока вы можете сделать программу с точки зрения «объектов, которые делают вещи», а не списка инструкций, или объявленного набора правил, или каскадного ряда функций ... реализация не имеет значения. Аналогично, изменение системы типов не лишает законной силы ни один из общих принципов ОО.

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

Как как язык позволяет это, не имеет значения.

— Telastyn
источник

На самом деле, Go делает все эти вещи ООП проще и добавляет несколько дополнительных возможностей , как расширение типа , чтобы обеспечить новый интерфейс применения существующих экземпляров ( до тех пор , пока вы не нужны новые элементы данных, конечно).

— Ян Худек

4

Я думаю, что ваша идея об ООП совсем немного

Я изобрел термин «объектно-ориентированное программирование», и это {Java и C ++} не то, что я имел в виду.
- Алан Кей .

Выбор типирования (номинативный подтип, структурный подтип или утка - или их комбинация) в значительной степени ортогональн к ООП. Наследование и классы полностью ортогональны ООП. Если вы потратите некоторое время, чтобы поиграть с io, вы увидите это.

Теперь вы можете спросить, какой тип системы «лучше», и какие средства повторного использования и комбинации кода. И попробуйте определить преимущества и недостатки между выбором, сделанным в Simula (а затем и в C ++, Java и C #), и выбором, сделанным в Go. Но это все разные и разные вопросы.

В конечном счете, ООП является очень расплывчатым понятием, и все попытки реализовать его имеют огромное разнообразие вкусов. Но чтобы действительно упростить вещи, я бы сказал, что основная идея ООП состоит в том, чтобы составлять системы подсистем SOLID . Теперь это абсолютно стирает грань с другими парадигмами, но я могу предположить, что именно поэтому в последнее время популярность мультипарадигмных языков возросла, и Google сделал свой собственный шаг в этом с Go.

— back2dos
источник

2

Вопрос относится к понятиям, а не к необходимому термину. Если вы можете придумать более подходящее имя, чем «ООП», чтобы обратиться к концепции иерархий классов и всей обрезки, которая идет с ним, тогда мы можем использовать это вместо этого.

— Tylerl

@tylerl: Вы путаете по крайней мере два вопроса в одном. Во-первых, является ли структурный подтип лучше номинативного подтипа. Другой вопрос заключается в том, лучше ли состав, чем наследование. Эти вопросы взаимно ортогональны. Я думаю, что в конечном итоге «лучший» язык не делает этот выбор для вас. Я бы предположил, что у Go просто другой набор проблем, но мы посмотрим, добавит ли Google эти функции «назад» или нет.

— back2dos

Я хотел бы только один язык, который имеет большинство возможностей C ++, но был меньше и проще. C ++ является единственным языком, кроме C, реалистичным для ядер, и он дает вам чрезвычайно полезные инструменты, такие как деструкторы и STL. И важный принцип «если вы не используете его, вы не платите за него». ОО, использованный правильно, чрезвычайно мощный. Но дженерики и другие не-ОО концепции также жизненно необходимы. С почти ничего не дает, а Го выбрасывает настоящий ОО за какие-то странные новомодные идеи.

— Эрик Алапяя,

1

ООП не устарел.

Как сказала Андреа, было предложено много концепций в качестве альтернативы классам (например, класс типов haskell). У ООП есть одно большое преимущество: его преподают во многих местах, и культура ООП широко распространена среди разработчиков.

Это позволяет более богатое общение внутри команды. О фабриках говорить проще, чем о скигистоморфных препроморфизмах . ООП структурирует способ организации и обмена информацией о вашей программе с помощью часто используемых диаграмм. Это мощный актив.

— Саймон Бергот
источник

1

Я думаю, что во многих местах. На самом деле это не преимущество.

— AndreasScheinert

@ AndreasScheinert, почему это не будет преимуществом?

— Саймон Бергот

Потому что, чтобы судить, вы должны знать, по крайней мере, 1 альтернативу одинаково хорошо. Это привычка, людям нравится оставаться в своей зоне комфорта, и это приводит к застою.

— AndreasScheinert

@AndreasScheinert использовать правильный инструмент для работы. Ой не работает для всех сценариев .... не имеет ничего общего с их зоной комфорта

— pqsk

1

Нет, здесь нет ничего нового, и ООП не устарел. C ++ также имеет неявные интерфейсы в форме шаблонов, но люди все еще используют виртуальные функции. Вам необходимы явные интерфейсы, например двоичные интерфейсы или интерфейсы, где другой код просто не известен во время компиляции.

Вы могли бы утверждать, что это просто случай умозаключения против его явного указания, что не имеет ничего общего с «новой парадигмой» и на самом деле просто более удобно.

— DeadMG
источник