Почему классы косвенно вытекают только из класса объекта?

Question

У меня нет никаких аргументов, противостоящих, почему нам нужен только один универсальный класс. Однако почему бы не иметь два универсальных класса, скажем, объект и класс антиобъекта. В природе и в науке мы находим концепцию двойственности - как энергия и темная энергия; Мужской женский; Плюс и минус; Умножьте и разделите; Электроны и протоны; Интеграция и вывод; и в теории наборов. Есть так много примеров дуализма, что само по себе является философией. В самом программировании мы видим анти-паттерны, которые помогают нам выполнять работу в отличие от того, как мы используем шаблоны дизайна. Я не уверен, но полезность этой концепции двойственности может заключаться в создании коллекционеров мусора, которые создают антиобъекты, которые в сочетании со свободными или свободными объектами, чтобы разрушить себя, тем самым освобождая память. Или могут быть антиобъективные работы вместе с объектами для создания самомодифицирующего языка программирования - который позволяет нам создавать безопасный код самостоятельного изменения, делать эволюционные вычисления с использованием генетического программирования, скрывать код для предотвращения обратной инженерии.

Мы называем это объектно-ориентированным программированием. Это ограничивающий фактор или есть что -то фундаментальное, что мне не хватает в понимании формирования языков программирования?

Answer 1

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

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

Во -первых, чтобы увеличить количество доступного полиморфизма. Это было особенно необходимо, прежде чем дженерики были добавлены в язык. Без объекта классы сбора были бы невозможно написать полезным способом.

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

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

Answer 2

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

С точки зрения наследования ничто не мешает классовой иерархии иметь несколько корней. Как указано в других народах, C ++, а также многие языки OO не ограничивают выразительность одним классом предков.

Однако из Тип теоретик Точка зрения (напомним, что наследование и подтипление - это не одно и то же, поэтому я, вероятно, выхожу из кадра основного вопроса здесь), один «верхний» супертип может иметь большой смысл (в зависимости от теории типа курс). Например, в OCAML существует общий супертип для всех объектов (будь то экземпляры класса или непосредственные объекты), написано < > Чтобы обозначить, что тип объекта пуст, т.е. не принимает никаких сообщений. Это действительно самый общий тип объекта, который мы можем определить, поскольку мы не можем ничего удалить из него, чтобы сделать его более общим. Следовательно, в этой концепции типов объектов обязательно существует супертип для всех объектов.

Что касается двойного объекта Root, Scala имеет класс под названием Nothing, который любопытно также пуст и является подтипом всех остальных классов. Его нельзя создавать, но содержит достаточно полезного семантического для реализации пустого списка, который называется Nil, и равен List[Nothing] (Как указывалось в комментариях, возможно, что программист никогда не использует это значение в большинстве случаев, что делает его казалось бы не таким полезным, как оно есть). Nothing можно считать двойным типа корня - называется Any В Scala, однако эти типы не только охватывают классы, но и примитивы, так что все может быть подтверждено Any, например.

Answer 3

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

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

Размывание различия между ценностями и сущностями затрудняет для типов сбора знать, следует ли они рассматривать свое содержание как ценности или объекты; Это, в свою очередь, ограничивает способность коллекций реализовать такие вещи, как equals или же clone полезно. Языки, которые делают более сильное различие типа/сущности, могут иметь коллекции, делают больше вещей автоматически, чем языки, которые нет, но различия добавляют некоторую сложность, которую дизайнеры языка могут или не могут чувствовать, оправданные преимуществами.