¿Por qué las clases derivan implícitamente de sólo el objeto de clase?

Question

No tengo ningún argumento opuesto por eso que necesitamos una única clase universal. Sin embargo ¿por qué no tenemos dos clases universales, digamos un objeto y una clase AntiObject. En la naturaleza y en la ciencia nos encontramos con el concepto de la dualidad - como la energía y la energía oscura; Macho femenino; Mas menos; Multiplicar y Dividir; Los protones y electrones; Integración y derivación; y en la teoría de conjuntos. Hay tantos ejemplos de dualidad que es una filosofía en sí mismo. En la programación en sí vemos anti-patrones que nos ayuda a realizar un trabajo en contraste con la forma en que utilizamos patrones de diseño. No estoy seguro, pero la utilidad de este concepto dualidad puede radicar en la creación de los recolectores de basura que crean AntiObjects que se combinan con objetos sueltos o libres para destruir a sí mismos, por lo tanto la liberación de memoria. O puede ser AntiObjects trabajan junto con los objetos para crear un lenguaje de programación auto-modificable - que nos permite crear un código de auto modificando segura, hacen uso de la computación evolutiva programación genética, hacen que oculta de código para evitar la ingeniería inversa.

Lo llamamos programación orientada a objetos. Es que un factor limitante o hay algo fundamental que me falta en la comprensión de la formación de los lenguajes de programación?

Answer 1

Esto es sólo una respuesta a responder a la pregunta en el título.

lenguajes como Java tienen todas las clases derivadas de objetos por dos razones.

En primer lugar, para aumentar la cantidad de polimorfismo disponible. Esto se requiere particularmente antes de añadir los genéricos para la lengua. Sin objetos, clases de colección sería imposible escribir de una manera útil.

En segundo lugar, hay muchos métodos que se espera que las clases de tener o son útiles, y éstos se recogen en objeto. Al asegurarse de que todas las clases heredan del objeto, todas las clases implementarán la misma interfaz mínima.

Como se mencionó en un comentario, C ++ no tiene una clase como objeto. C ++ es de muchas maneras sin tipo, por lo que los temas que menciono anteriormente no son aplicables. Además, las plantillas de C ++ proporcionan una gran cantidad de polimorfismo y se utilizan para implementar colecciones.

Answer 2

Creo que las cubiertas respuesta aceptada más o menos la pregunta original, pero me gustaría complementarlo (si es posible) ligeramente por tirar (informalmente) algunas ideas con respecto a las cuestiones secundarias.

Desde el punto de vista de la herencia, nada impide que la jerarquía de clases para tener varias raíces. Como se ha señalado por otros pueblos, C ++, así como muchos lenguajes orientados a objetos hacen expresividad no limitación a una única clase ancestro raíz.

Sin embargo, a partir de un tipo teórico punto de vista (recordemos que la herencia y de subtipos no son la misma cosa, así que estoy probablemente Al salir del marco de la cuestión principal aquí), una sola " superior" supertipo puede hacer mucho sentido (dependiendo del tipo teoría, por supuesto). Por ejemplo, en OCaml, hay un supertipo común a todos los objetos (si las instancias de la clase, o los objetos inmediatos), < > escritas para indicar que el tipo de objeto está vacía, es decir, no se hace ningún mensaje. Esto parece de hecho el tipo de objeto en general más que podemos definir, ya que no podemos quitar nada de él para que sea más general. Por lo tanto, en esta concepción de tipos de objetos, no es necesariamente un supertipo para todos los objetos.

En cuanto al doble del objeto raíz, deportes scala una clase llamada Nothing, que curiosamente también está vacía, y es el subtipo de todas las otras clases. No se pueden crear instancias, pero mantiene lo suficientemente útil semántica para implementar la lista vacía, que se llama Nil, y es igual a List[Nothing] (como fuera de punta en los comentarios, es posible que el programador nunca use directamente ese valor en la mayoría de casos, por lo que es aparentemente no tan útil como lo es). Nothing se podría considerar un doble del tipo de raíz -. Any llamada en Scala, sin embargo, estos tipos no sólo cubren las clases, sino también las primitivas tipos, por lo que todo se puede upcasted a Any, por ejemplo

Answer 3

La capacidad de definir colecciones que pueden contener tipos arbitrarios de las cosas, sin necesidad de definir diferentes métodos para diferentes tipos de cosas, es muy útil. Plantillas en C ++ que sea posible que un solo archivo de origen para definir tipos de colección que pueden contener muchos tipos diferentes de cosas, pero el compilador tendrán que duplicar el código para cada diferente tipo de cosas en la colección. Si en lugar uno define casi todos los tipos en el sistema que se derivan de un solo tipo, a continuación, una colección que puede contener referencias a cosas de ese tipo será capaz de referencias HOLD para cosas de casi cualquier tipo.

Este método tiene una limitación, sin embargo, que es que se difumina las diferencias entre los valores y las entidades. Una referencia que encapsula un valor mediante la identificación de un objeto particular, se puede reemplazar con una referencia a una copia de ese objeto sin alterar su semántica. Una referencia que se utiliza para identificar una entidad, sin embargo, puede no ser sustituido de tal manera. Ya sea la propia entidad será algo que no se puede copiar (por ejemplo, si representa una conexión con algo en el mundo real) o la entidad puede encapsular el conjunto de referencias que existen para que . Un punto clave a destacar es que los objetos se comportan como valores cuando cualquiera que no pueden cambiar o sólo existe una referencia a ellos, y se comportan como entidades cuando existen varias referencias.

Borrando la distinción entre los valores y las entidades hace que sea difícil para los tipos de colección para saber si deben considerar su contenido como valores o entidades; esto a su vez limita la capacidad de las colecciones de implementar cosas como equals o clone de manera útil. Idiomas que hacen una distinción tipo / entidad más fuerte pueden tener colecciones de hacer más cosas de forma automática de idiomas que no lo hacen, pero las distinciones añadir un poco de complejidad, lo que los diseñadores de lenguajes pueden o no sientan se justifican por los beneficios.