В чем смысл ООП?

Реальный мир не является "OO", и идея, подразумеваемая в OO-что мы можем моделировать вещи с помощью некоторой классовой таксономии-кажется мне очень фундаментально ошибочной

В то время как это верно и было замечено другими людьми (возьмем Степанова, изобретателя STL), rest-это нонсенс. OOP может быть ошибочным, и это, конечно, не серебряная пуля, но это делает крупномасштабные приложения намного проще, потому что это отличный способ уменьшить зависимости. Конечно, это справедливо только для дизайна “good” OOP. Небрежный дизайн не даст никакого преимущества. Но хороший, несвязанный дизайн может быть очень хорошо смоделирован с использованием OOP и не очень хорошо с использованием других методов.

Есть гораздо лучшие, более универсальные модели (на ум приходит модель типа Haskell ), но они также часто более сложны и/или трудны для эффективной реализации. OOP-это хороший компромисс между крайностями.

ООП-это не создание повторно используемых классов, это создание пригодных для использования классов.

Слишком часто используется этот класс просто для своего синтаксического сахара; он помещает функции для типа записи в их собственное маленькое пространство имен.

Да, я тоже нахожу это слишком распространенным явлением. Это не объектно-ориентированное программирование. Это объектно-ориентированное программирование и ориентированное на данные Программирование. За 10 лет работы с OO языками я вижу, что люди в основном занимаются объектным программированием. OBP ломается очень быстро IMHO, так как вы по существу получаете худшее из обоих слов: 1) процедурное программирование без соблюдения доказанной методологии структурированного программирования и 2) OOP без соблюдения доказанной методологии OOP.

35 правильно сделанное-прекрасная вещь. Это делает очень трудные проблемы легко решаемыми, и для непосвященных (не пытайтесь там звучать напыщенно) это может показаться почти волшебством. Тем не менее, OOP-это всего лишь один инструмент в наборе инструментов методологии программирования. Это не есть методология "будь всем" и "закончи все". Это просто хорошо подходит для больших бизнес-приложений.

Большинство разработчиков, работающих на языках OOP, используют примеры OOP, сделанные правильно в рамках и типах, которые они используют day-to-day, но они просто не знают об этом. Вот несколько очень простых примеров: ADO.NET, Hibernate/NHibernate, фреймворки ведения журнала, различные типы языковых коллекций, стек ASP.NET, стек JSP и т. д... Это все вещи, которые сильно полагаются на OOP в своих кодовых базах.

Повторное использование не должно быть целью OOP - или любой другой парадигмы, если на то пошло.

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

Мысль о OO как о новом способе повторного использования через наследование в корне ошибочна. Как вы заметили, LSP нарушений предостаточно. Вместо этого OO правильно рассматривается как метод управления сложностью проблемной области. Цель-поддержание работоспособности системы во времени. Основным инструментом для достижения этой цели является отделение публичного интерфейса от частной реализации. Это позволяет нам иметь правила, такие как "это должно быть изменено только с помощью..."принудительный компилятор, а не проверка кода.

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

На грани религиозности, но я бы сказал, что вы рисуете слишком мрачную картину современного состояния OOP. Я бы сказал, что это действительно снизило затраты, сделало большие программные проекты управляемыми и так далее. Это не означает, что он решил фундаментальную проблему беспорядка программного обеспечения, и это не означает, что средний разработчик является экспертом OOP. Но модульизация функции на объектные компоненты, безусловно, уменьшила количество спагетти-кода в мире.

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

Но в той степени, в какой OOP был пустой тратой времени, я бы сказал, что это из-за отсутствия подготовки программиста, усугубленной крутой кривой обучения изучению языка, специфичного для OOP отображения. Некоторые люди "get" OOP, а другие никогда не будут.

Нет никаких эмпирических доказательств того, что объектная ориентация является более естественным способом для людей думать о мире. Есть некоторые работы в области психологии программирования, которые показывают, что OO не является каким-то более подходящим, чем другие подходы.

Объектно-ориентированные представления не кажутся универсально более или менее пригодными для использования.

Недостаточно просто принять методы OO и потребовать от разработчиков использовать такие методы, поскольку это может негативно сказаться на производительности разработчиков, а также на качестве разрабатываемых систем.

Который находится от "On the Usability of OO Representations" из сообщений ACM Oct. 2000 год. В статьях в основном сравнивается OO с подходом, ориентированным на процесс. Существует множество исследований того, как люди, работающие с OO методом "think" (Int. Ж. человеко-компьютерных исследований, 2001, выпуск 54, или взаимодействие человека с компьютером 1995, вып. 10 имеет целую тему по OO исследованиям), и из того, что я читал, нет ничего, что указывало бы на некоторую естественность подхода OO, что делает его более подходящим, чем более традиционный процедурный подход.

Я думаю, что использование непрозрачных контекстных объектов (HANDLEs в Win32, FILE*s в C, чтобы назвать два хорошо известных примера-черт возьми, HANDLEs живут по другую сторону барьера kernel-mode, и это действительно не становится намного более инкапсулированным, чем это) также находится в процедурном коде; я изо всех сил пытаюсь понять, как это что-то особенное для OOP.

HANDLE s (и rest из WinAPI) - это OOP! C не очень хорошо поддерживает OOP, поэтому нет специального синтаксиса, но это не значит, что он не использует те же самые понятия. WinAPI - это во всех смыслах слова объектно-ориентированная структура.

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

Это парадигма программирования.. Он был создан для того, чтобы нам, простым смертным, было легче разбить проблему на более мелкие, выполнимые части..

Если вы не находите это полезным.. Не используйте его, не платите за обучение и будьте счастливы.

С другой стороны, я действительно нахожу это полезным, поэтому я буду :)

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

Другие аспекты OOP, включая наследование и полиморфизм, также важны, но, как упоминали другие, они обычно используются слишком часто. т. е.: Иногда люди используют наследование и / или полиморфизм, потому что они могут, а не потому, что они должны иметь. Они являются мощными концепциями и очень полезны, но должны использоваться с умом и не являются автоматическими выигрышными преимуществами OOP.

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

Проблема с OOP заключается в том, что он был перепродан.

По первоначальному замыслу Алана Кея, это была отличная альтернатива прежней практике получения необработанных данных и общемировых процедур.

Затем какие-то менеджеры-консультанты ухватились за него и продали как мессию программного обеспечения, а вслед за ним, подобно леммингу, посыпались научные круги и промышленность.

Теперь они, как лемминг, кувыркаются после перепродажи других хороших идей, таких как функциональное программирование.

Так что же я буду делать по-другому? Много, и я написал об этом книгу. (Это уже не печатается - я не получаю ни цента, но вы все равно можете получить копии.) Amazon

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

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

Он возвышает понятие domain-specific-languages (DSLs). Он решительно соглашается с DRY (не повторяйтесь). Это дает большой палец вверх для генерации кода. Это приводит к тому, что программное обеспечение имеет значительно меньшую структуру данных, чем это характерно для современных приложений.

Он стремится вновь возродить идею о том, что путь вперед лежит в изобретательности и что даже хорошо принятые идеи должны быть подвергнуты сомнению.

HANDLEs (а rest из WinAPI) - это OOP!

Хотя они,? Они не наследуются, они, конечно, не могут быть заменены, у них нет четко определенных классов... Я думаю, что они далеко не дотягивают до "OOP".

Вы когда-нибудь создавали окно с помощью WinAPI? Затем вы должны знать, что вы определяете класс (RegisterClass ), создаете его экземпляр ( CreateWindow), вызываете виртуальные методы ( WndProc ) и методы базового класса ( DefWindowProc) и так далее. WinAPI даже берет номенклатуру из SmallTalk OOP, вызывая методы “messages” (сообщения окна).

Дескрипторы могут не передаваться по наследству, но тогда в Java есть final . Они не лишены класса, они являются заполнителем для класса: вот что означает слово “handle”. Глядя на такие архитектуры, как MFC или .NET WinForms, сразу становится ясно, что, кроме синтаксиса, ничего особенного не отличается от WinAPI.

Да OOP не решило всех наших проблем, извините за это. Однако мы работаем над SOA, который решит все эти проблемы.

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

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

Тем не менее, когда присутствует хороший дизайн OO, это просто чистая радость, читая код и видя, что код естественным образом вписывается в интуитивную components/classes. я всегда воспринимал системную архитектуру и дизайн, как проектирование различных отделов и рабочих мест персонала в компании - все они предназначены для выполнения определенной части работы в общей схеме вещей, излучая синергию, необходимую для продвижения организации/системы вперед.

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

ООП хорошо поддается программированию внутренних компьютерных структур, таких как GUI "widgets", где, например, SelectList и TextBox могут быть подтипами элемента, который имеет общие методы, такие как "move" и "resize".

Проблема в том, что 90% из нас работают в мире бизнеса, где мы работаем с такими бизнес-концепциями, как счет, сотрудник, работа, заказ. Они не так хорошо подходят для OOP, потому что "objects" более туманны, подвержены изменениям в соответствии с реинжинирингом бизнеса и так далее.

Наихудший случай - это когда OO с энтузиазмом применяется к базам данных, включая вопиющие базы данных от OO "enhancements" до SQL, которые справедливо игнорируются, за исключением нубов базы данных, которые полагают, что они должны быть правильным способом делать вещи, потому что они новее.

Может быть, шляпка, колени или дерево-это не стул, но все они ISittable.

Я думаю, что эти реальные вещи мира являются объектами

А ты знаешь?

Какие методы есть у счета-фактуры? О, подожди. Он не может заплатить сам, не может отправить сам себя, не может сравнить себя с товарами, которые поставщик фактически доставил. У него вообще нет никаких методов, он абсолютно инертен и нефункционален. Это тип записи (структура, если вы предпочитаете), а не объект.

Точно так же и другие вещи, которые вы упоминаете.

Просто потому, что что-то реально, это не делает его объектом в смысле OO этого слова. Объекты - это своеобразная связь состояния и поведения, которые могут действовать сами по себе. Это не то, что есть в изобилии в реальном мире.

Я писал код OO в течение последних 9 лет или около того. Кроме использования обмена сообщениями, мне трудно представить себе другой подход. Главное преимущество, которое я вижу, полностью соответствует тому, что сказал CodingTheWheel: модульность. OO естественно приводит меня к созданию моих приложений из модульных компонентов, которые имеют чистые интерфейсы и четкие обязанности (т. е. слабо связанный, очень связный код с четким разделением проблем).

Я думаю, что где OO ломается - это когда люди создают глубоко вложенные наследственные классы. Это может привести к усложнению ситуации. Однако разложение общей финкциональности на базовый класс, а затем повторное использование этого в других классах-потомках-это глубоко элегантная вещь, IMHO!

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

Тем не менее, OO-это другой способ организации вещей, прикрепление процедурного кода к данным, а не использование процедурного кода для работы с данными. Это должно быть по крайней мере небольшой победой само по себе, так как есть случаи, когда подход OO является более естественным. В конце концов, ничто не мешает кому-либо написать процедурный API в C++, и поэтому возможность предоставления объектов вместо этого делает язык более универсальным.

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

Недостатком является то, что good OO не является бесплатным: он требует времени и усилий, чтобы изучить его должным образом. Поскольку это главное модное слово, есть много людей и продуктов, которые делают это плохо, просто ради того, чтобы сделать это. Создать хороший интерфейс класса не проще, чем хороший процедурный API, и есть все виды ошибок easy-to-make (например, глубокие иерархии классов).

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

@Sean

Однако разложение общей финкциональности на базовый класс, а затем повторное использование ее в других классах-потомках-это глубоко элегантная вещь, IMHO!

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

@Konrad

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

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

На мой взгляд, в самом синтаксисе OOP есть много полезного. Использование объектов, которые пытаются представить реальные вещи или структуры данных, часто гораздо более полезно, чем попытка использовать кучу различных плоских (или "floating") функций для выполнения одного и того же действия с одними и теми же данными. Есть определенный естественный "flow" для вещей с хорошим OOP, который просто имеет больше смысла читать, писать и поддерживать в долгосрочной перспективе.

Не обязательно важно, что счет - фактура на самом деле не является "object" с функциями, которые он может выполнять сам-экземпляр объекта может существовать только для выполнения функций над данными без необходимости знать, какой тип данных на самом деле существует. Функция " invoice.toJson() " может быть успешно вызвана без необходимости знать, что такое данные "invoice" - результат будет Json, независимо от того, если он исходит из базы данных, XML, CSV или даже другого объекта JSON. С процедурными функциями вы внезапно должны узнать больше о своих данных и в конечном итоге получить такие функции, как "xmlToJson()", "csvToJson()", "dbToJson()", и т.д. В конечном итоге это становится полным беспорядком и головной болью HUGE, если вы когда-нибудь измените базовый тип данных.

Смысл OOP заключается в том, чтобы скрыть фактическую реализацию, абстрагировав ее. Для достижения этой цели необходимо создать общедоступный интерфейс. Чтобы сделать вашу работу проще при создании этого открытого интерфейса и сохранить вещи DRY, вы должны использовать такие понятия, как абстрактные классы, наследование, полиморфизм и шаблоны проектирования.

Таким образом, для меня реальная первостепенная цель OOP-облегчить дальнейшее обслуживание и изменения кода. Но даже помимо этого, он действительно может значительно упростить вещи, когда делается правильно, так, как никогда не мог бы сделать процессуальный кодекс. Не имеет значения, если он не соответствует "real world"-Программирование с кодом не взаимодействует с объектами реального мира в любом случае. OOP - это всего лишь инструмент, который делает мою работу проще и быстрее - я готов пойти на это в любой день.

@CodingTheWheel

Но в той степени, в какой OOP был пустой тратой времени, я бы сказал, что это из-за отсутствия подготовки программиста, усугубленной крутой кривой обучения изучению специфического языка OOP mapping. Некоторые люди "get" OOP, а другие никогда не будут.

Хотя я не знаю, действительно ли это удивительно. Я думаю, что технически обоснованные подходы (LSP-это очевидная вещь) трудно использовать , но если мы не используем такие подходы, это делает код хрупким и нерастяжимым в любом случае (потому что мы больше не можем рассуждать об этом). И я думаю, что противоречивые результаты, к которым приводит нас OOP, делают неудивительным то, что люди не воспринимают его.

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

@Jeff

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

Который имеет более скрытую реализацию: iostreams C++или C FILE*s?

Я думаю, что использование непрозрачных контекстных объектов (HANDLEs в Win32, FILE*s в C, чтобы назвать два хорошо известных примера-черт возьми, HANDLEs живут по другую сторону барьера kernel-mode, и это действительно не становится намного более инкапсулированным, чем это) также находится в процедурном коде; я изо всех сил пытаюсь понять, как это что-то особенное для OOP.

Я полагаю, что это может быть частью того, почему я изо всех сил пытаюсь увидеть преимущества: части, которые явно хороши, не являются специфичными для OOP, в то время как части, которые специфичны для OOP, не являются явно хорошими! (это не означает, что они обязательно плохи, а скорее то, что я не видел доказательств того, что они широко применимы и последовательно полезны).

В единственном блоге dev, который я читал, у этого парня Joel-On-Software-Founder-of-SO, я давным-давно прочитал, что OO не приводит к повышению производительности. Автоматическое управление памятью делает это. Круто. Кто может отрицать эти данные?

Я все еще считаю, что OO для не-OO-это то же самое, что программирование с функциями для программирования всего встроенного.

(И я должен знать, так как начал с GWBasic.) Когда вы рефакторируете код для использования функций, variable2654 становится variable3 из метода, в котором вы находитесь. Или, еще лучше, у него есть имя, которое вы можете понять, и если функция коротка, она называется value , и этого достаточно для полного понимания.

Когда код без функций становится кодом с методами, вы можете удалить мили кода.

Когда вы рефакторинг кода, чтобы быть по-настоящему OO, b , c , q , Z и стать this , this , this и this . И поскольку я не верю в использование ключевого слова this , вы можете удалить мили кода. На самом деле, вы можете сделать это, даже если используете this .

Я не думаю, что OO-это естественная метафора.

Я также не думаю, что язык-это естественная метафора, и я не думаю, что "smells" Фаулера лучше, чем сказать "this code tastes bad.", что сказал, Я думаю, что OO-это не естественные метафоры, и люди, которые думают, что объекты просто выскакивают на вас , в основном упускают суть. Вы определяете объектную вселенную, и лучшие объектные вселенные приводят к коду, который короче, легче понять, работает лучше или все это (и некоторые критерии я забываю). Я думаю, что люди, которые используют customers/domain's природных объекта в качестве объектов программирования, не имеют возможности переопределить вселенную.

Например, когда вы создаете систему бронирования авиабилетов, то, что вы называете бронированием, может вообще не соответствовать юридическому/деловому бронированию.

Некоторые из основных концепций являются действительно классными инструментами

Я думаю, что большинство людей преувеличивают всю эту историю с "when you have a hammer, they're all nails". Я думаю, что другая сторона медали / зеркала так же верна: когда у вас есть гаджет, подобный polymorphism/inheritance,, вы начинаете находить применение там, где он подходит, как glove/sock/contact-lens. Инструменты OO очень мощные. Одиночное наследование, я думаю, абсолютно необходимо для того, чтобы люди не увлекались, мое собственное программное обеспечение для множественного наследования не выдерживает.

Какой смысл в OOP?

Я думаю, что это отличный способ справиться с абсолютно массивной кодовой базой. Я думаю, что это позволяет вам организовывать и реорганизовывать ваш код и дает вам язык для этого (помимо языка программирования, на котором вы работаете), а также модулирует код довольно естественным и easy-to-understand способом.

OOP суждено быть неправильно понятым большинством разработчиков

Это происходит потому, что это процесс открытия глаз, как и жизнь: вы понимаете OO все больше и больше с опытом, и начинаете избегать определенных шаблонов и использовать другие, когда становитесь мудрее. Одним из лучших примеров является то, что вы перестаете использовать наследование для классов, которые вы не контролируете, и предпочитаете вместо этого шаблон фасада .

Относительно вашего mini-essay/question

Я действительно хотел сказать, что вы правы. Повторное использование-это по большей части несбыточная мечта. Вот цитата из Андерса Хейльсберга на эту тему (блестящая) отсюда :

Если вы попросите начинающих программистов сделать это написать элемент управления "календарь", они часто подумайте про себя: "О, я собираюсь ... напишите лучший в мире календарь контроль! Он будет полиморфным что касается вида календаря. Он будет иметь отражателях, и mungers, и это, и то, и другое." Они необходимо отправить приложение календаря в два месяца. Они все это положили инфраструктура на месте в контролируйте, а потом потратьте два дня написание дерьмового приложения календаря на вершине всего этого. Они подумают: "в самом деле! следующая версия приложения, я я собираюсь сделать гораздо больше."

Как только они начинают думать о том, как они на самом деле собираются реализовать все эти другие конкретизации их абстрактный дизайн, однако, это оказывается, что их конструкция такова совершенно неправильный. А теперь они ушли они сами себя загнали в угол, и они должны бросить все это дело из. Я видел это снова и снова. Я твердо верю в бытие минималистичный. Если только ты на самом деле им не являешься собираемся решить общую проблему, не пытайтесь поставить на место рамки для решения конкретной задачи, потому что вы не знаете что это за рамки должно выглядеть так.

Вы когда-нибудь создавали окно с помощью WinAPI?

Больше раз, чем мне хотелось бы помнить.

Затем вы должны знать, что вы определяете класс (RegisterClass), создаете его экземпляр (CreateWindow), вызываете виртуальные методы (WndProc) и методы базового класса (DefWindowProc) и так далее. WinAPI даже берет номенклатуру из SmallTalk OOP, вызывая методы “messages” (сообщения окна).

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

Дескрипторы могут быть не наследуемыми, но тогда в Java есть final. Они не лишены класса, они являются заполнителем для класса: вот что означает слово “handle”. Глядя на такие архитектуры, как MFC или .NET WinForms, сразу становится ясно, что, кроме синтаксиса, ничего особенного не отличается от WinAPI.

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

Неужели это действительно так? Лучшие биты OOP-это просто... традиционный процессуальный кодекс? В этом-то все и дело?