¿Por qué OOP se aplica en Java y C #? [cerrado]

6

En muchos otros idiomas, como C ++ y Javascript, OOP es opcional. El código de procedimiento está bien. Pero en lenguajes como Java y C #, OOP es algo forzado. Todo es ser parte de una clase o un objeto. ¿Cuáles son los beneficios?

    
pregunta Gulshan 21.02.2011 - 17:00

15 respuestas

14

Tanto C # como Java están marcados como lenguajes conocidos no por lo que habilitan, sino por lo que deshabilitan , en términos del conjunto de funciones que utilizan. (C # menos en estos días con LINQ, pero eso es una lata de gusanos completamente diferente) Ambos lenguajes están diseñados de tal manera que es más difícil crear malos diseños, a costa de cierta libertad para el programador. En general, el diseño orientado a objetos produce diseños más reutilizables y mantenibles que los diseños no orientados a objetos. (Nota: digo "en general" aquí: algunos diseños se expresan más fácilmente usando (por ejemplo) primitivas de programación funcional) Por lo tanto, OO es el paradigma predeterminado admitido en estos idiomas.

(Una vez más, C # es un poco extraño aquí porque es compatible con el estilo de programación funcional)

    
respondido por el Billy ONeal 21.02.2011 - 18:10
12

No es tanto que se aplique OOP, como se aplica un marco OOP. Es posible escribir programas de procedimiento en Java, aunque es más fácil si solo son un archivo.

La ventaja es la uniformidad. Hay varios tipos diferentes de funciones y datos en C ++, y esto causa algunos problemas y confusiones a veces, y al menos es más que aprender. Con Java, tienes funciones miembro (basadas en clase u objeto) y datos similares, y eso es todo.

Esto tiene como objetivo hacer que Java sea más fácil de leer y escribir, especializando un poco el lenguaje.

    
respondido por el David Thornley 21.02.2011 - 17:14
9

Podría ser "ellos pensaron que era una buena idea en ese momento", es decir, no tener funciones libres. Hace 10-15 años, el mundo del desarrollo estaba entusiasmado con "Orientado a objetos" (tal como todos parecen estar entusiasmados con "Agile" en este momento).

Aun así, no estoy seguro de que todas las clases deban derivarse de Object, pero sin los genéricos en los que debe realizar el lanzamiento todo el tiempo, ayuda y podría ser la practicidad que la VM que construyeron en ese momento era capaz de manejarlo mejor

MFC de Microsoft tenía un concepto de CObject también en la parte superior de una gran jerarquía.

    
respondido por el CashCow 21.02.2011 - 18:05
6

En mi experiencia, la mayoría de los ejemplos horribles de código de mierda He visto que está escrito en Java o C #. He visto algunas cosas malas en lenguajes menos estrictos, pero no es nada en comparación con los horrores absolutos de mirar al abismo de 1.000.000 líneas de código C # de bola de barro estático copiado.

No sé por qué, pero supongo que es más fácil, incluso posible, seguir agregando más y más (y más ...) código en Java / C #, con la certeza de que el compilador le dirá cuando su sintaxis es incorrecta. Desafortunadamente, no te dice cuando tu diseño es incorrecto.

No estoy diciendo que Java / C # sea malo o algo así, todo lo contrario. Es solo que toda esta ayuda, la aplicación de la seguridad de tipos hace posible desordenar las cosas mucho más que en lenguajes más flexibles y no exigentes.

Así que realmente no puedo decir que esta política de "cumplimiento" ha mejorado la calidad del código en general. Sin embargo, ha mejorado la cantidad de código, eso es seguro.

    
respondido por el Martin Wickman 21.02.2011 - 18:57
4

C # 2.0 agregó soporte para static classes cuando salió hace 6-7 años. Eso convierte a una clase en un "módulo" (o "espacio de nombres" que depende de su elección de jerga) que no contiene más que métodos y campos estáticos, lo que le permite aplicar efectivamente la definición y el consumo de tipos de estilo que no sean OOP.

A menudo se recomienda OOP, pero ciertamente no se aplica. Se sorprendería de la cantidad de bibliotecas .NET implementadas como clases estáticas.

    
respondido por el Rei Miyasaka 30.03.2011 - 13:12
3

Mucha gente piensa que OOP es la mejor manera de escribir código. Son correctos, incorrectos o abiertos a opiniones / debates ... no importa. Aquellos que escribieron Java / C # obviamente creen lo primero.

Es más fácil aplicar OOP como un estándar de codificación si el propio lenguaje lo impone. Esta es también la razón por la que los lenguajes como Java te obligan a hacer otras cosas, como una clase pública por archivo.

Tienen algo de un punto allí. Es difícil hacer que la gente haga las cosas como tú quieres. Dales demasiada libertad y lo hacen a su manera y esperan que lo haga a través de la revisión. Si las herramientas las obligan a una determinada forma de hacer las cosas, entonces no tiene que discutir y / o conseguir el consenso del equipo (que todos ignoran rápidamente).

Por otro lado, nunca estuve realmente de acuerdo con nada de Java. Por un lado, hay excepciones a todas las reglas y Java simplemente no proporciona eso.

    
respondido por el Crazy Eddie 21.02.2011 - 19:08
3

No se aplica, después de todo, como dice el dicho: un desarrollador real puede escribir el código FORTRAN en cualquier idioma.

Pero tengo que admitir que no entiendo la esencia de la pregunta. ¿Bueno, por qué no? Hay tantos idiomas por ahí, por lo que Gosling y sus amigos se dispusieron a crear uno basado solo en clases y objetos (bueno, y algunos tipos primitivos). La idea no fue completamente innovadora, pero también querían legibilidad, sintaxis tipo C y bases sólidas y abstractas.

Cada retraso representa una compensación entre la libertad y la aplicación estricta de un conjunto de principios que ayudan a evitar errores. El montaje te da total libertad y también todas las oportunidades posibles para dispararte en el pie. Ada fue diseñada para darte muy poca libertad pero también menos oportunidades de autodestrucción. Uno no es intrínsecamente mejor que el otro.

Java es solo un lenguaje que se inclina hacia el extremo más estricto del espectro, más estricto que C ++ pero que no se sumerge en las profundidades verdaderas de la tipificación fuerte.

C # es algo más fácil de explicar, fue la respuesta de Microsoft a la popularidad de Java (y sus intentos fallidos de colar clases propietarias en su implementación del marco de applet :)).

    
respondido por el biziclop 21.02.2011 - 23:13
3

Para cumplir con el requisito de cumplimiento de palabras de moda.

(Esto solo se entiende en parte como una broma, pero es cierto).

Estos lenguajes están dirigidos a empresas, y el tomador de decisiones promedio en BigCorporation no entiende las técnicas de programación, pero lee en todas partes que OOP es el futuro.

Al menos, esto solía ser cierto hace 5 a 15 años.

Hoy en día, las startups están produciendo muchos más productos que las grandes corporaciones, por lo que Java y C # terminaron perdiendo (de alguna manera). Debido a que pretendían complacer al gerente intermedio despistado, los tipos de personas más técnicos y de hackers utilizaron diferentes tecnologías (php, ruby, python, y más recientemente: node.js).

    
respondido por el hasen 22.02.2011 - 07:16
3

C ++ se construyó (originalmente) sobre C, que es de procedimiento. Los programas C ++ todavía tienen una función 'principal' como punto de entrada de un programa, que es un legado de procedimiento.

JavaScript está orientado a objetos, pero se basa en el modelo de prototipo y delegación en lugar de un modelo de clase y herencia (estos modelos son funcionalmente equivalentes e igualmente válidos). El marco OO dentro de JavaScript es implícito. Solo porque puedes escribir

<script> var i=21*15; </script>

no significa que realmente estés usando código de procedimiento; bajo el capó, ha creado implícitamente un método anónimo que pertenece al objeto Document [advertencia: supongo que en función de la depuración del DOM; Expertos en JavaScript, por favor, corrija]

Java y C # fueron diseñados para estar orientados a objetos usando el modelo de clase y herencia, por lo tanto, cada programa debe tener una clase (estática) y un punto de entrada principal. Sin embargo, más allá de eso, eres libre de ser tan procesal como quieras.

    
respondido por el Steven A. Lowe 29.03.2011 - 17:04
2

Su pregunta no es por qué estos idiomas son compatibles con OOP sino por qué no permiten OOP. En particular, supongo que eso significa que no permiten funciones simples que no sean miembros de ninguna clase.

Parece que la respuesta más simple es que el soporte haría que esos lenguajes más sean complejos (considere que los espacios de nombres y la resolución de sobrecarga deberían ser capaces de manejar funciones simples y esas características ya son complejas ) a cambio de poco beneficio: siempre puede hacer programación de procedimientos usando funciones estáticas. ¿Qué beneficio real te darían las funciones que no son de clase?

    
respondido por el munificent 21.02.2011 - 20:13
2

No se trata de "forzar" las cosas. Es simplemente que algunas soluciones pueden expresarse puramente en conceptos OO, por lo que el lenguaje proporciona solo conceptos OO.

    
respondido por el Philluminati 21.02.2011 - 21:35
2

Esta es una suposición descabellada, pero una razón podría es que hace que la magia IDE como IntelliSense sea más fácil / más útil. En C ++, todas las funciones de la biblioteca estándar de C se encuentran en el espacio de nombres global. Cada clase y función de la biblioteca estándar de C ++ está en el espacio de nombres std . Y muchos programas de C ++ en los que he trabajado también ponen todo en el espacio de nombres global (o usé using namespace XYZ al principio de cada archivo). Por lo tanto, si presiona Ctrl-Space en algún lugar de un archivo, obtendrá una larga lista de muy de cada función global. En C #, todas las funciones estáticas como Math.Sin o Buffer.BlockCopy están contenidas en un espacio de nombres. Así que todo lo que obtienes cuando presionas Ctrl-Space son algunas clases como Math , Buffer , ...

    
respondido por el nikie 21.02.2011 - 22:16
1

Un lenguaje es solo una abstracción sobre el código de ensamblaje. La elección de la abstracción simplemente está ahí para ayudarlo a resolver un problema (haciendo que las tareas específicas sean más fáciles de hacer bien y ciertos problemas son más difíciles de hacer mal).

Tenían que elegir una abstracción. Y como lo veo (ignorando todas las razones comerciales) C # fue la abstracción conceptual sobre C ++ que fue la abstracción sobre C excepto con las clases (OO). C # simplemente intentó reforzar el modelo OO y resolver problemas como la pérdida y el retiro de memoria de algunas de las complejidades de bajo nivel.

Si no es adecuado para su dominio de problemas, simplemente elija el idioma apropiado con la mejor abstracción para su dominio de problemas.

    
respondido por el Stephen Bailey 30.03.2011 - 21:02
1

Según lo indicado por otros. ¡No lo es!

Si quieres saber por qué es (o casi lo es), mira a Eiffel. Vale la pena echarle un vistazo; Puedes aprender Eiffel más rápido que C # o Java.

Finalmente entenderás OO, diseño por contrato, herencia, propiedades de C # y mucho más.

    
respondido por el ctrl-alt-delor 29.03.2011 - 13:52
0

Un punto que no se ha mencionado es que en muchos marcos orientados a objetos basados en la recolección de basura, es absolutamente imprescindible que el sistema sepa el paradero de cada referencia de objeto, no solo cada objeto, sino todas las referencias también, en cualquier momento en que se pueda producir la recolección de basura; Si hay un subproceso Th en el que el sistema no conoce el paradero de cada referencia de objeto y la recolección de basura se hace necesaria, todos los demás subprocesos deben esperar a que el subproceso Th llegue a un punto donde el sistema sepa dónde sus referencias de objeto son.

El requisito anterior es mucho más estricto que cualquier cosa que exista para C o C ++. En C o C ++, se puede construir una unión que combine un tipo numérico entero con un puntero, y siempre que el código realice un seguimiento de si la cosa contiene un entero o un puntero, no importará si el marco de tiempo de ejecución puede decir qué tipo la cosa es. Tal enfoque no funcionaría en un lenguaje recogido en la basura. Si interpretar el contenido de una unión como un puntero haría referencia a un objeto que se está reubicando, entonces es absolutamente imperativo que el contenido de la unión se actualice para mantener la nueva dirección si la última cosa almacenada era un puntero, pero es igualmente imperativo que se deje solo si se supone que tiene un entero. Simplemente, no hay nada que el tiempo de ejecución pueda hacer de forma segura si no puede requerir que las referencias de objetos se almacenen en ubicaciones de almacenamiento del tipo de referencia de objetos y en ningún otro lugar.

    
respondido por el supercat 11.07.2012 - 09:17

Lea otras preguntas en las etiquetas