Search This Blog

Showing posts with label Java. Show all posts
Showing posts with label Java. Show all posts

Sunday, 16 March 2014

C # y Java: Comparación de Lenguajes de Programación


 
 
 
 
 
i
 


Java
Tanto C # y Java son “puros” lenguajes orientados a objetos
Cualquier clase en ambos idiomas implícita (o explícita) subclases de un objeto. Esta es una muy buena idea, ya que proporciona una clase base predeterminada de una clase definida por el usuario o incorporado. C + + sólo puede simular este apoyo a través del uso de punteros void, lo que es problemático para muchas razones, incluyendo la seguridad de tipos. ¿Por qué es C # y Java, además de bueno? Bueno, por un lado, permite la creación de contenedores muy genéricas. Por ejemplo, los dos idiomas tienen clases pila predefinidos, que permiten código de aplicación para empujar cualquier objeto a una instancia de pila inicializado, a continuación, llamar pop más adelante, que elimina y devuelve la referencia al objeto superior al llamador-suena como la definición clásica de una pila . Naturalmente, esto por lo general requiere que el desarrollador para convertir la referencia aparecido de nuevo a alguna clase de objeto derivado de más específico de modo que alguna operación significativa (s) se puede realizar, pero en realidad el tipo de todos los objetos que existen en cualquier instancia de la pila debe ser realmente conocido en tiempo de compilación por el promotor de todos modos. Esto es, al menos, porque a menudo es difícil hacer algo útil con un objeto si la interfaz pública de la clase es desconocido cuando hace referencia a un objeto después apareció. (Reflexión, una característica muy potente en ambos idiomas, se puede utilizar en un objeto genérico. Pero un desarrollador sería necesario para defender fuertemente su uso en este escenario
Tanto C # y Java tienen soporte para el manejo formal de excepción, como C + +. ¿Por qué la gente siente la necesidad de manejo de excepciones, sin embargo? Después de todo, las lenguas existen que no tienen este apoyo, y los desarrolladores son capaces de escribir código con idiomas que funciona correctamente. Pero sólo porque algo funciona no significa que sea necesariamente bueno. Creación de funciones mediante el manejo formal de excepción se puede reducir en gran medida la complejidad del código en el servidor y en el cliente. Sin excepciones, las funciones deben definir y devolver un valor no válido en el lugar de un ser válida en caso de que no se cumplan las condiciones previas. Esto puede ser problemático, ya que la definición de un valor no válido puede eliminar al menos un elemento de otra manera válida en el rango de función. Y puede ser un poco incómodo ya que el cliente debe entonces comprobar el valor devuelto contra algunos inválida uno predefinido. (Otras soluciones han sido juzgados, entre ellos: 1) añadir una referencia booleana no const extra para cada llamada a la función, y haga que el método establecido en true si el éxito y false. 2) Establecer un parámetro global, por lo menos el contexto del subproceso de llamada, que define el último error que un cliente puede comprobar después de las llamadas de función. Estos son lejos de satisfacer, y pueden requerir un desarrollador de aplicaciones para tener demasiado conocimiento acerca de cómo funcionan las cosas “bajo las sábanas.”)


http://msdn.microsoft.com/en-us/library/ms836794.aspx

Tuesday, 13 August 2013

C# and Java: Comparing Programming Languages





 
Both C# and Java Are "Pure" Object-Oriented Languages

Any class in either language implicitly (or explicitly) subclasses an object. This is a very nice idea, because it provides a default base class for any user-defined or built-in class. C++ can only simulate this support through the use of void pointers, which is problematic for many reasons, including type safety. Why is this C# and Java addition good? Well, for one, it allows the creation of very generic containers. For example, both languages have predefined stack classes, which allow application code to push any object onto an initialized stack instance; then call pop later, which removes and returns the top object reference back to the caller—sounds like the classic definition of a stack. Naturally, this usually requires the developer to cast the popped reference back to some more specific object-derived class so that some meaningful operation(s) can be performed, but in reality the type of all objects that exists on any stack instance should really be known at compile-time by the developer anyway. This is at least because it is often difficult to do anything useful with an object if the class's public interface is unknown when later referencing some popped object. (Reflection, a very powerful feature in both languages, can be used on a generic object. But a developer would be required to strongly defend its use in this scenario

Both C# and Java have support for formal exception handling, like C++. Why do people feel the need for exception handling, though? After all, languages exist that do not have this support, and developers are able to write code with these languages that works correctly. But just because something works doesn't mean that it's necessarily good. Creating functions using formal exception handling can greatly reduce code complexity on both the server and client side. Without exceptions, functions must define and return some invalid value in place of a valid one just in case preconditions are not met. This can be problematic since defining an invalid value may remove at least one otherwise valid item in the function range. And it can be messy because the client must then check the return value against some predefined invalid one. (Other solutions have been tried, among them: 1) add an extra non-const Boolean reference to every function call, and have the method set it to true if success else false. 2) Set a global parameter, for at least the calling thread's context, which defines the last error that a client can test after function calls. These are far from satisfying, and they may require an application developer to have too much knowledge about how things work "under the covers.")