Переваги класичного OOP над Go-подібною мовою

Я багато думав про дизайн мови та про те, які елементи будуть потрібні для "ідеальної" мови програмування, а вивчення Google Go Go спонукало мене до сумнівів у багатьох інакше загальних знаннях.

Зокрема, Go, здається, має всі цікаві переваги від об'єктно-орієнтованого програмування, не маючи насправді жодної структури об'єктно-орієнтованої мови. Не існує класів, лише структури; не існує спадкування класу / структури - лише вбудовування структури. Немає ніяких ієрархій, батьківських класів, явних реалізацій інтерфейсу. Натомість правила кастингу типу базуються на нещільній системі, подібній до типізації качок, так що якщо структура реалізує необхідні елементи "Reader" або "Request" або "Encoding", ви можете надати її та використати як один.

Чи є щось про OOP, як це реалізовано в C ++ та Java та C #, що за своєю суттю є більш здатним, більш доступним, якимось потужнішим, що вам доведеться відмовитися, переходячи до такої мови, як Go? Якої ви користі відмовитися, щоб отримати простоту, яку представляє нова парадигма?

EDIT
Видалено "застаріле" питання, яке, здавалося, читачам було надмірно затримане та розлючене.

Питання полягає в тому, що може запропонувати традиційна об'єктно-орієнтована парадигма (з ієрархіями тощо), що часто зустрічається в загальних мовних реалізаціях, що в цій простішій моделі неможливо зробити так просто? Або, інакше кажучи, якби ви сьогодні розробляли мову, є причина, яку ви хочете включити в поняття ієрархії класів?

Немає нової парадигми. Орієнтація на об'єкт - це шаблон, який ви використовуєте для написання програм, який навіть чітко не визначений. Різні мови надають різні ознаки, характерні для орієнтації на об'єкти (визначення нових типів, інкапсуляція, ієрархії типів, поліморфізм, передача повідомлень тощо), але можуть не надати інших. У цих випадках програмісти повинні наслідувати їх, якщо виникає потреба.

Багато мов, які надають ці функції, не мають аналога поняття класу - наприклад, Javascript та Common Lisp. Реалізація, що надається Java-подібними мовами (на основі класів, з єдиним успадкуванням, інтерфейсами, на основі типів), є лише однією з можливостей, не обов'язково найкращою.

Якої ви користі відмовитися, щоб отримати простоту, яку представляє нова парадигма?

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

Чи застаріла така система застарілу концепцію ООП?

Ні. Поки ви можете скласти програму з точки зору "об'єктів, які роблять речі", а не з переліком інструкцій, або заявленого набору правил, або каскадної серії функцій ... реалізація не має значення. Так само зміна системи типів не приводить до недійсності жодного із загальних принципів ОО.

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

Як мова дозволяє, це насправді не має значення.

Я думаю, що Ваша ідея про ООП зовсім не така:

Я вигадав термін "Об'єктно-орієнтоване програмування", і це {Java і C ++} - це не те, що я мав на увазі.
- Алан Кей .

Вибір введення тексту (номінативний підтип, структурний підтипізація або типізація качок - або їх комбінація) значною мірою ортогональний для ООП. Успадкування та заняття повністю ортогональні для ООП. Якщо вам знадобиться якийсь час, щоб пограти з io, ви приїдете до цього.

Тепер ви можете запитати, який тип типів систем "кращий", а також які засоби повторного використання та комбінації коду. І спробуйте визначити переваги та недоліки між варіантами, зробленими в Simula (а пізніше здійсненими в C ++, Java та C #), та тими, які зроблені в Go. Але це все різні і чіткі питання.

Зрештою, OOP - це дуже розпливчаста концепція, і всі спроби її втілення мають різноманітні смаки. Але для дійсного спрощення речей я б сказав, що основна ідея OOP полягає у створенні систем підсистем SOLID . Тепер це абсолютно розмиває межу з іншими парадигмами, але я б припускав, що це причина, чому мови багатопарадигми останнім часом набули популярності і чому Google взяв власну думку з Go.

OOP не застаріло.

Як сказала Андреа, було запропоновано багато концепцій як альтернативу класам (наприклад, тип класу haskell). OOP має одну велику користь: її викладають у багатьох місцях, а культуру ООП багато в чому поділяють серед розробників.

Це дає змогу покращити спілкування всередині команди. Про фабрики можна говорити простіше, ніж про зигогістоморфні препроморфізми . OOP структурує спосіб організації та спілкування своєї програми за допомогою часто використовуваних діаграм. Це потужний актив.

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

Ви можете стверджувати, що це просто випадок висновку проти чіткого викладу, який є не що інше, як "нова парадигма" і справді просто зручніший.