#25170 Investigan como llenar los cráteres
EDIT: Quedaba mejor cuando tu comentario finalizaba en lunas. Ahora con lo otro ya qda peor este xD
#25169 llevo en el "mundo" de la informática desde los 10 años, aunque como programador desde hace 2 años.
bueno, juya, gadi ch bedel smichik?
#25170 Principalmente tenemos 3 vías:
1-Investigamos (y implementamos) mejoras para que con los mismos recursos (o menos, a poder ser), obtengamos más(o mejores) resultados, EJ: Él último de este tipo destacable es que antes tramitar un servicio con compañia X llevaba entre 3 y 4 minutos, después de la automatización se tardan entre 30 y 60 segundos.
2- Desarrollamos herramientas para que los franquiciados (y nuestros tralleres) puedan realizar su trabajo de forma eficaz, intentamos mejorar la eficiencia y la confianza que ponen en nosotros facilitandole herramientas (y escuchando sus necesidades para ver que podemos hacer, etc), EJ: El último de este tipo destacable ha sido la implementación de un buscador de referencias de lunas gráfico, que permite a usuarios sin muchos conocimientos en lunas de coche encontrar la referencia que buscan.
3- Hacemos explotación de sistemas informaticos, tratando de aprovechar al máximo la información que poseemos para mejorar la toma de decisiónes
hombre... antes de ser fpero era técnico informático... :S
de los pocos devs que sepan formatear un ordenador que te vas a encontrar.
#25180 Ahí pone ' de qué estás hablando? ', a lo que le tienes que contestar ' तुला एक टोक पाहिजे का? '
#25182 Te lo ha puesto antes de tu pregunta:
3- Hacemos explotación de sistemas informaticos, tratando de aprovechar al máximo la información que poseemos para mejorar la toma de decisiónes
#25186 Lo que mejor se te da hacer son cuentas hacía atrás, verdad?
Si te pones a programar en un avión, la gente que tienes sentada al lado se pone nerviosa?
#25164 No se me permite pasar el código interno, además de que a lo mejor un día me pongo a dejarlo arregladito y cambiar cuatro cosas y hago una librería con él 
pero te hago un ejemplito rápido.
Tomemos como referencia una hipotética clase para tarjetas; queremos que pueda haber dos tipos de tarjetas distintos: informativos e interactivos.
Definimos el componente de la tarjeta. Generalmente no tendrá mucha lógica; ésta irá más bien en la clase controladora, pero sí que se pueden poner algunas cosas a este nivel (por ejemplo, ocultar el contenido y cosas así). Para este caso usaré un componente súper básico:
Creas la template, preparándote para todas las ocasiones a las que vas a enfrentarte. En este caso, unas tarjetas simples con texto, y otras con botones:
(me falta un elvis operator ahí, esto pasa por hacer las cosas a correr xd, pero debería funcionar igual en teoría).
Creas las capas de abstracciones. Este ejemplo es tan chorras que hay una forma mejor de hacer esto (pues no usamos ningún método), pero creo que se pilla fácil en este ejemplo cuáles son las posibilidades. Generalmente, en casos más complejos la superclase debería ser abstracta, pero ya que en este caso las implementaciones complejas son sólo extensiones funcionales de la clase principal (tarjeta => tarjeta con botoncicos) no hace falta:
Creas una instancia de la clase controladora con los datos que desees. Por simplicidad, aquí defino las propiedades al vuelo y pista, pero generalmente sacarías el contenido de una base de datos y así. Como ya dije antes, dada la simplicidad del ejemplo, sería tan fácil esto como asignar a "card" un objeto con todas las propiedades aquí definidas, pero en un ejemplo real, al usar métodos, requerirías de hacer una instancia completa con "new", tal y como hago aquí:
Finalmente, a nivel de template del parent component le pasas la referencia a tu instancia de clase controladora:
Para la próxima ya tienes una idea 
#25191 Sí, es un ejemplo muy sencillito. La idea es ceñirse a este concepto y aprovecharlo a tope: yo por ejemplo en la abstracción de tablas que te conté antes, tengo en mi AbstractTable todos los métodos relativos a ordenación, a sacar los valores para cada columna de una forma determinada del objeto de datos, y así. Y luego en las implementaciones puedes hacer de todo ya... por ejemplo ¿necesitas otra forma de ordenación (me ha pasado)? Pues re-implementas el método. Y cosas así.
Al final te quitas una de curro que flipas de encima, y poco a poco hasta te van quedando jerarquías tope guapas y aprovechables que cada vez serán más sólidas. Me parece curioso no haber visto este approach a los componentes de Angular en otro lado, por eso vine a preguntar de primeras.
edit: para este ejemplo concreto, no hubiese hecho esto, me parece importante recalcarlo. Con los parámetros opcionales de las interfaces haces lo mismo sólo que mucho más rápido.
#25192 La comunidad de angular se pasa por el forro los estándares de manera general, solo tienes que ponerte a mirar repos de github para ver cosas totalmente ilógicas, que carecen totalmente de utilidad o parece que les paguen por linea de código.
Mucho pajeet trabajando con angular.
#25193 Eso lo puedes extrapolar a Javascript en general y es el problema principal del lenguaje.
Yo personalmente lo que veo mucho, es diseño demasiado centrado puramente en el paradigma funcional, en lugar de aprovechar uno de los fuertes por excelencia del JS de hoy en día: aprovecharlo junto a OOP. Ni que fueran cosas excluyentes, vaya. Yo a día de hoy mezclo ambas cosas y estoy contento con cómo está quedando el código y lo fácil que está haciéndose de mantener (lo cual suele ser el lastre de las cosas (mal) hechas con JS).
