c# - practices - ¿Todo en.NET es un objeto?

generate documentation c#

Question

Ayúdenos a resolver la controversia de "Casi" todo es un objeto ( una respuesta a la pregunta de Stack Overflow Como novato, ¿hay algo de lo que deba tener cuidado antes de aprender C #? ). Pensé que ese era el caso, ya que todo en Visual Studio al menos aparece como una estructura. Por favor, publique una referencia para que no se convierta en "moderno idiota" ( This American Life ).

Tenga en cuenta que esta pregunta se refiere a C #, no necesariamente .NET, y cómo maneja los datos bajo el capó (obviamente son todos 1 y 0).

Aquí están los comentarios a "todo es un objeto":

• Eh, no, no lo es. - Binary Worrier
• Me gustaría un ejemplo ... - scotty2012
• no es todo derivado del tipo de objeto base? - rizzle
• La mayoría de las cosas son objetos ... - Omar Kooheji
• Los tipos de valores, ints, dobles, referencias de objetos (no los objetos mismos) etc. no son objetos. Se pueden "encasillar" para que parezcan objetos (egIToString ()) pero realmente son tipos primitivos. Cambie la entrada a "CASI TODAS las cosas son un objeto" y eliminaré el voto negativo - Binary Worrier
• Aprecio la aclaración. Creo que el nivel más bajo con el que puedes interactuar, digamos int, en C # es como una estructura, ¿qué no es un objeto? - http://msdn.microsoft.com/en-us/library/ms173109.aspx - rizzle
• ¿Int32 hereda de ValueType que hereda de Object? Si es así, a pesar del comportamiento, un int es un objeto. - Chris Farmer
• No, el tipo encuadrado para int hereda de ValueType, que hereda de Object. No son objetos en el sentido tradicional porque a) un int no es una referencia a un int, ES el int. b) los enteros no son basura recolectada. Si declara un Int32, entonces ese int tiene 4 bytes en la pila, al final de la historia - Binary Worrier

Definición de objeto: "Objeto" como un heredero de la clase System.Object vs. "object" como una instancia de un tipo vs. "objeto" como un tipo de referencia. "

Answer 1

Algunas personas aquí tienen una extraña noción de lo que es un "objeto" en la programación orientada a objetos. Para que algo sea un objeto, no tiene por qué ser un tipo de referencia o, más en general, seguir una implementación formal.

Todo lo que eso significa es que puedes operarlo como un ciudadano de primera clase en un mundo orientado a objetos. Como puedes hacer esto en valores en C # (gracias al autoboxing), todo es realmente un objeto. Hasta cierto punto, esto es cierto incluso para las funciones (pero posiblemente no para las clases).

Si esto es relevante en la práctica es otra cuestión, pero este es un problema general con OOP que noto una vez más. Nadie tiene clara la definición de OOP (sí, la mayoría de las personas está de acuerdo en que tiene algo que ver con el polimorfismo, la herencia y la encapsulación, y algunos la consideran "abstracta").

Desde un punto de vista de uso, cada valor en C # se maneja como un objeto. Dicho esto, me gusta la respuesta actualmente aceptada. Ofrece ambos aspectos técnicamente importantes.

Tenga en cuenta que en otros contextos, por ejemplo, C ++, se enfatizan otros aspectos, ya que C ++ no está necesariamente orientado a objetos y, además, está mucho más centrado en aspectos de bajo nivel. Por lo tanto, la distinción entre objetos, POD y primitivas incorporadas a veces tiene sentido (luego nuevamente, a veces no).

Answer 2

Basado en todos los libros que leo, todo en C # es un objeto.

Algunos son referencia otros son tipo de valor. El tipo de valor del objeto hereda de la clase ValueType . Tienen un comportamiento diferente pero inherentemente ... objetos.

Esta es la razón por la que puede almacenar un Int32 en una variable de objeto, así como todo lo que pueda crear en .NET.

Para obtener más detalles ... consulte lo siguiente: msdn.microsoft.com/en-us/library/s1ax56ch(VS.71).aspx

Todos los tipos de valores se derivan implícitamente de la clase Object.

Answer 3

C # ha sido se conoce como un sistema de tipo unificado. Eso significa que todo se puede ver como un objeto. Sin embargo, debajo de esto hay dos tipos diferentes: tipos de valores y tipos de referencia. Los tipos de valores se pueden ver como un objeto a través del mecanismo de boxeo. Esto significa que se crea un objeto que representa el valor del tipo de valor en cuestión.

Answer 4

De: Tipos de valor (referencia C #) - MSDN 3.5

Todos los tipos de valores se derivan implícitamente de System.ValueType.

De: ValueType

ValueType anula los métodos virtuales de Object con implementaciones más apropiadas para los tipos de valores.

De: Clase Enum - MSDN 3.5

Esta clase hereda de ValueType

La Jerarquía de herencia es la siguiente:

• System.Object
  • System.ValueType
    • System.Enum

Conclusión: todo es un objeto

Answer 5

Depende de lo que quiere decir con "todo" y con "es un objeto". Si define estos dos términos, la respuesta es fácil :-)

Por ejemplo, en algunos idiomas, un bloque-if es un objeto que se puede pasar como un valor, asignado a una variable y así sucesivamente. Este no es el caso en C #, así que claramente no todo es un objeto en C #.

Answer 6

Dirigiéndose a la semántica, ¿por qué sobrecargar la palabra "objeto" para que signifique "tipo de referencia" cuando ya tenemos un término perfectamente bueno, inequívoco para eso -> "Tipo de referencia", y el cuándo, al sobrecargar la palabra "Objeto" en de esta manera creamos la confusión que este hilo demuestra ... es decir, la falta de coincidencia entre el hecho de que todos los tipos (incluidos los tipos de valores) heredan la implementación definida en el Tipo "System.Object". Claramente, esto es, en el mejor de los casos, innecesario y, en el peor de los casos, extremadamente confuso. Incluso el hecho de que la documentación de EM sea a veces confusa sobre este tema no es excusa para propagar la confusión.

Mucho más fácil y más claro es simplemente definir y usar el término "objeto" para significar una instancia de CUALQUIER tipo, valor o referencia, y la frase "Tipo de referencia" para describir los Tipos que usan variables de puntero y tienen su estado almacenado en el Heap ...

Answer 7

El número 2 no es un objeto.

Answer 8

El problema aquí es que realmente se trata de dos preguntas: una pregunta es acerca de la herencia, en cuyo caso la respuesta es "casi todo" y la otra es sobre el tipo de referencia frente al tipo de valor / memoria / boxeo, en cuyo caso la respuesta es "no" ".

Herencia:

En C #, lo siguiente es verdadero:

• Todos los tipos de valores, incluidas las enumeraciones y los tipos anulables, se derivan de System.Object .
• Todos los tipos de clase, matriz y delegado se derivan de System.Object .
• Los tipos de interfaz no se derivan de System.Object . Todos son convertibles a System.Object , pero las interfaces solo se derivan de otros tipos de interfaz, y System.Object no es un tipo de interfaz.
• Ningún tipo de puntero se deriva de System.Object , ni ninguno de ellos es directamente convertible a System.Object .
• Los tipos de parámetros de tipo "abierto" tampoco se derivan de System.Object . Los tipos de parámetros de tipo no se derivan de nada; Los argumentos de tipo están limitados a derivarse de la clase base efectiva, pero ellos mismos no se "derivan" de nada.

Desde la entrada de MSDN para System.Object :

Admite todas las clases en la jerarquía de clases de .NET Framework y proporciona servicios de bajo nivel para las clases derivadas. Esta es la última clase base de todas las clases en .NET Framework; es la raíz de la jerarquía de tipos.

Los lenguajes normalmente no requieren una clase para declarar la herencia de Object porque la herencia es implícita.

Dado que todas las clases en .NET Framework se derivan de Object, todos los métodos definidos en la clase Object están disponibles en todos los objetos del sistema. Las clases derivadas pueden anular algunos de estos métodos y lo hacen.

Entonces, no todos los tipos en C # se derivan de System.Object . E incluso para los tipos que sí lo son, aún debe tener en cuenta la diferencia entre los tipos de referencia y los tipos de valores , ya que se tratan de forma muy diferente.

Boxeo:

Mientras que los tipos de valor heredan de System.Object , se tratan de forma diferente en la memoria de los tipos de referencia, y la semántica de cómo se pasan a través de los métodos en su código también es diferente. De hecho, un tipo de valor no se trata como un Objeto (un tipo de referencia), hasta que explícitamente le indique a su aplicación que lo haga boxeándolo como un tipo de referencia. Ver más información sobre el boxeo en C # aquí .

Answer 9

En C # (y en OOP en general) tenemos tipos (clase - referencia, estructura - valor, etc.). Estas son las definiciones. Y el "objeto" es la instancia concreta de un tipo dado.

Entonces, si leemos la pregunta literalmente, sí, todo es un objeto cuando se crea una instancia.

La confusión probablemente comience con una mala elección del nombre de la clase base para todo. En .NET esta es la clase Object.

Answer 10

Estás confundiendo un objeto con un valor o referencia. Básicamente, todo es un objeto. Un Int es un objeto, pero también es un tipo de valor. Una instancia de clase es un objeto, pero también es un tipo de referencia.

Los métodos no son objetos, ni son propiedades. Simplemente opera en objetos. Y sí, casi todo lo hereda de la clase de objetos.

Answer 11

Esta es una discusión de dos mundos: lenguaje y memoria.

Para mí, el lenguaje es como una capa de abstracción y el término objeto pertenece a este nivel de abstracción. No veo un punto para hablar de objetos en términos de organización de memeoría y si usas el término "objeto" cuando hablas de memoria, en realidad estás tomando prestado este término de una capa diferente de abstracción. Por lo tanto, no debes olvidar de dónde vino.

Si estamos hablando de C #, no entiendo por qué alguien usaría la organización de la memoria como argumento. Por supuesto, si respondiera esta pregunta a alguien, diría: "Sí, en C # todo es un objeto, pero también debes saber que bajo el capó puede funcionar de manera diferente, dependiendo de ..."

Esto puede comenzar un argumento interesante, pero también puede hablar con algunos: en una discusión similar uno podría decir que en realidad no hay programación orientada a objetos, solo hay programación de procedimientos. ¿La CPU entiende los objetos? Incluso mejor, en realidad no hay software, solo hay diferentes estados de hardware :)

Mi punto es que algunos términos no se traducen en otras capas de abstracción y debes pegar la discusión en donde pertenece (que en este caso es un lenguaje, no una memoria).

Incluso el autor de esta pregunta afirmó: "Tenga en cuenta que esta pregunta se refiere a C # no necesariamente .NET y cómo maneja los datos bajo el capó (obviamente son todos 1 y 0)".

Answer 12

Los tipos de valores no son objetos, obedecen a diferentes semánticas de copia, semánticas de pasos diferentes, y deben estar envueltos en una clase (Objeto) para poder ser tratados como tales.

Editar: Creo que el argumento es algo vago, ya que debes calificar lo que quieres decir con ''objeto''. ¿Es un objeto algo que hereda de Object, o es algo que obedece a la semántica de uso de Object? ¿O estamos hablando de la definición más general de objeto, donde es algo que puede contener datos y operaciones sobre esos datos?

Answer 13

Pensé que los tipos de valores NO son objetos. El CLR los almacena de forma diferente en la memoria: los tipos de valores se almacenan en la pila y los objetos se almacenan en el montón. Puede convertir tipos de valor a un tipo de referencia para que actúen como un objeto, pero el CLR quita el valor de la pila, lo envuelve en un objeto y lo almacena en el montón. Eso es lo que sucede cuando "caja" una variable.

Answer 14

Si bien todos parecen centrarse en los tipos de valores frente al debate sobre tipos de referencia, estamos olvidando un tipo en C # que no es ni referencia ni valor, no se deriva de un objeto y no se puede convertir en objeto: punteros.

A diferencia de los valores y tipos de referencia, los punteros no se pueden convertir a objeto.

De acuerdo con la documentación de MSDN sobre los tipos de punteros C # ,

Los tipos de puntero no heredan del objeto y no existen conversiones entre los tipos de puntero y el objeto. Además, el boxeo y el desempaquetado no son compatibles con los punteros. Sin embargo, puede convertir entre diferentes tipos de punteros y entre tipos de puntero y tipos integrales.

Answer 15

Teniendo en cuenta que la pregunta se refiere a Object en un sentido de OOP, las respuestas son:

Desde un punto de vista técnico , la respuesta es: no

Desde un punto de vista dogmático la respuesta es: Sí

Explicación:

Técnicamente, los tipos de valor (primitivas o estructuras) no son objetos a menos que estén en forma de "recuadro", sino porque .Net realiza conversiones continuas de tipos de valor a su contraparte Objeto mediante el acto de boxeo / unboxing (creando una instancia de clase que contiene el valor y se deriva de Object) que significa que los tipos de valores se pueden tratar como objetos y valores simples.

Entonces, los tipos de valores son de naturaleza dual, se comportan como valores y como objetos . Los valores en .Net son Objetos cuando deben serlo, y no son objetos en el resto de los casos.

La respuesta correcta que tiene en cuenta el aspecto técnico es "Todo en .Net es como si fuera un Objeto".

La respuesta dogmática es "Todo es un Objeto".

Answer 16

Todos son tratados como objetos, pero no son todos objetos. La confusión viene con Autoboxing.

Consulte esto para obtener más información: http://en.wikipedia.org/wiki/Object_type

La abstracción confunde a las personas aparentemente.

Answer 17

Un poco tarde para la fiesta, pero me encontré con esto en un resultado de búsqueda en SO y pensé que el siguiente enlace ayudaría a las generaciones futuras:

Eric Lippert discute esto muy a fondo , con una declaración mucho mejor (calificada):

La forma de corregir este mito es simplemente reemplazar "deriva de" con "es convertible a", e ignorar los tipos de puntero: cada tipo no puntero en C # es convertible en objeto.

La esencia de esto, si odias leer explicaciones bien ilustradas de personas que escriben lenguajes de programación, es que (con los punteros a un lado), cosas como Interface o declaraciones de tipo de parámetro genérico ("T") no son objetos, pero se garantiza que son tratable como objetos en tiempo de ejecución, porque tienen una instancia definida, que será un Objeto. Otros tipos (Tipo, Enum, Delegado, clases, etc.) son todos Objetos. Incluyendo los tipos de valor, que se pueden encasillar para objetar, como se ha discutido en otras respuestas.