Java no me gusta en el foro de Programación:

Y paso a explicar el porque de mi situacion:
Supongamos un ejemplo bien básico, en el cual tenemos una CuentaBancaria que seria una clase abstracta, y dos clases mas, CuentaCorriente y CajaAhorro que heredan de CuentaBancaria.
Tambien vamos a tener una clase Cliente, y dos subclases, ClienteEmpresa y ClienteFamilia.
CuentaBancaria conoce a su Cliente, uno y solo uno para este ejemplo.
Ahora CuentaBancaria implementa un método darPrestamo(int cantidad), y el límite del prestamo no lo decide la cuenta, sino el Cliente, de modo que cliente implementa:
int prestamoMaximo()
A su vez, el prestamo maximo podria depender del tipo de cuenta, pero hasta aca alcanza para explicar el asunto.
Ademas de lo asqueroso que me resulta declarar los tipos de absolutamente todo, esta operación que es muy sencilla requiere que me pase mas tiempo haciendo upcasting que implementando la propia solución.
Lo único que le agradezco a java es tener jdownloader en linux, pero paso de trabajar con java. Me guardo mi opinion de eclipse para bardear con todo respeto en una posible proxima emision Saludos

en todo caso lo que no te gusta no es Java, sino POO (tu ejemplo, aunque no se si lo termino de entender, se aplica también por ej a C#, Php, C++, etc)

En cuanto a tu ejemplo: si darPrestamo depende tanto del cliente como de la clase especifica de la cuenta bancaria, entonces, DEBES declararlo como un método abstracto y listo (cada una de las subclases lo tiene que implementar).

En cuanto a lo de "tengo que declarar todo" .... yo por el contrario amo los lenguajes fuertemente tipados (te aseguro que es menos costoso escribir más que debuggear); igual, buscate casi cualquier IDE que vas a ver como te simplifica la declaración de tipos (y de yapa te muestra la documentación de los mismo "on the fly"; algo que es muy difícil de lograr en lenguajes no tipados, y te aseguro que es un ventaja considerable; si no, programa contra cualquier librería más o menos grande o hace un sistema más o menos grande y vas a ver como pasas el 80-90% te la pasas perdiendo el tiempo en cosas como "hu pero esta función como era que se llamaba?"). Eclipse por ej (aunque como todo, el primer tiempo vas a putear porque vas a perder tiempo en aprender a usarlo/entenderlo; el tema siempre es "a la larga").
En cuanto a lo "estoy todo el tiempo haciendo upcasting", y... no entiendo que es upcasting, pero en general, hay un regla empírica que dice que "si estás haciendo mucho casting, es porque tenes un mal diseño" (y esto no te lo dicen en "la escuela" , pero un "mal diseño" vienen muchas veces por querer meter jerarquías de clases innecesarias; en general "un diseño OO puede ser incluso peor que un diseño no-OO").
Yo estoy desarrollandando un sistema contable/comercial; ya debo haber creado cerca de 100 clases... sabes cuantas veces use herencia? Una sola vez, y con bastantes reparos (la use porque era una forma relativamente "elegante" de factorizar código común; pero en general el mismo efecto se puede lograr mediante otros diseños). En general, la herencia es muy linda para los teóricos y para darle el gusto a los profesores, en la practica es perjudicial si se la usa incorrectamente y de "prepo" (algo similar al goto, pero al revés jaja).
Un ejemplo: en el sistema existen los conceptos de Clientes y Proveedores. POO diria "claro ejemplo de herencia; las dos clases heredan de Persona!". Situación real: "si, mi vieja también es un persona, pero Clientes y Proveedores se almacenan en distintas tablas en la base de datos, los procesos de negocio en los que intervienen son completamente distintos, las modulos de acceso a datos de las dos entidades son y deben ser independientes, los permisos de modificación de las mismas deben ser distintos, las posibilidades que un cliente real sea también un proveedor real son muy pocas, la clase Clientes y Proveedores es mejor que sean desarrolladas de manera completamente independiente, incluso por personas distintas, meter una clase en el medio complica todo, incluso cosas básicas como la compilación.... asi que, la herencia vamos a dejarla para otro día; existen muchas más diferencias prácticas que similitudes "teóricas/ontológicas"; acá hacemos programas, no filosofía.

En realidad no, me encanta POO, y de hecho, el ejemplo que puse es bastante objetoso, darPrestamo se encuentra en la clase CuentaBancaria la cual es abstracta como dije, y por lo tanto las subclases lo tienen que implementar.
Con respecto a tu ejemplo, si, es mas lo que complicas heredando de persona que lo que ganas. Como en tu ejemplo tenes razón, lo que te digo es que dependiendo del caso, podria convenir usar herencia, y ahi te pasa lo de mi ejemplo.
Con eclipse el único problema que tengo es que consume demasiados recursos para lo que hace (o mas bien para lo que hago), uso pdt y esta muy bueno, f3 para ir a la declaración es muy útil como decis.
Con php tambien se puede declarar el tipo de un parametro, pero es opcional, entonces si sirve se usa, hay casos en los que esta bueno tenerlo. Por ahí no fui muy claro con lo que dije, pero a mi esa protección me da la sensación de que pretende hacerse cargo de los descuidos del programador, y es verdad lo que decis, en mas de una te resuelve un quilombo, pero el precio es a mi gusto muy alto. Saludos