.net - que - ¿Qué se necesita para ser un mejor programador OO?
mejor lenguaje de programacion web (19)
Lo que funciona para mí:
Conozca el dominio de su aplicación y manténgase cerca del dominio el mayor tiempo posible, evitando la duplicación de código.
No se adhiera a un idioma, aprenda varios OO. Smalltalk, Comon Lisp, Python, Javascript tienen formas muy interesantes de implementar OOP. Explore su fuente (el navegador de objetos Smalltalk es una gran herramienta para eso).
Implemente una OOP lib en un lenguaje que no tenga un estándar OOP, como Lua: esto le mostrará que
self/thispuede ser más que un primer argumento implícito apuntando al estado, y delegando su comportamiento a suclass/vtable/metatable( que a su vez puede delegar la llamada a suclassprincipal).
¡Aclamaciones!
Tengo casi 6 años de experiencia en desarrollo de aplicaciones usando tecnologías .net. Con los años he mejorado como un mejor programador OO, pero cuando veo código escrito por otros tipos (especialmente los de Jeffrey Richter, Peter Golde, Ayende Rahien, Jeremy Miller, etc.), siento que hay una brecha generacional entre el mío y su diseños. Normalmente diseño mis clases sobre la marcha con la ayuda de herramientas como ReSharper para la refactorización y la organización de códigos.
Entonces, mi pregunta es "¿qué se necesita para ser un mejor programador OO". Lo es
a) Experiencia
b) Libros (referencia, por favor)
c) Proceso (tdd o uml)
d) patrones
e) ¿algo más?
Y cómo debería uno validar que el diseño es bueno, fácil de entender y de mantener. Como hay tantas palabras de moda en la industria como la inyección de dependencia, IoC, MVC, MVP, etc., donde uno debería concentrarse más en el diseño. Siento que la abstracción es la clave. ¿Qué más?
Además de aprender de material académico como libros y artículos, lo recomiendo encarecidamente : aprender más de un idioma, especialmente si proviene de una corriente principal Java / C #. Aprenda ruby, aprenda groovy, aprenda smalltalk, aprenda ceceo, aprenda las diferencias entre ambos en teoría y en la práctica.
Un ejemplo académico pero excelente es el despacho simple o múltiple: puede verificar la entrada de la wikipedia y ver por usted mismo cómo escribiría un código diferente dependiendo de las capacidades del idioma. Más fundamentalmente, esto le ayuda a comprender cómo lograr los mismos efectos en el lenguaje X mientras mantiene un diseño sólido.
La clave aquí es experimentar, comprender y evolucionar. También aprendes mucho de leer o ayudar en algunos proyectos de código abierto, por lo general tienen una buena arquitectura e implementación (al menos las grandes).
Hola y buen día para todos
Como Cheery dijo: "te vuelves un mejor programador orientado a objetos al olvidar la orientación de objetos por momento y te orientas a escribir programas mejores y más limpios mientras mejoras tus programas existentes".
Esa es la clave: piense y obtenga la solución más simple posible y codifique de manera similar
Eso es todo sin más ... adiós
Los primeros libros, necesitarás conocer algunos de los patrones GoF, pero lo más importante es que debes entender los principios detrás de los patrones. Comprenda las diferencias entre el estilo antiguo (uso de la herencia para la reutilización de código) y el estilo nuevo (prefiera la encapsulación sobre la herencia) o el diseño. Dos buenos libros para leer son: Patrones de diseño explicados por Shalloway y Trott y Agile Software Development, Principles, Patterns and Practices por Bob Martin.
Entonces necesitas experiencia. La teoría en los libros es buena, pero debes ajustar tu sentido de cuándo usar qué. Cómo usar el proceso para afinar sus diseños (Steven A. Lowe ya nombró iteraciones) muchos programas antiguos y antiguos describen programación iterativa y oo-programación en los mismos documentos y libros.
Y por último, pero creo que lo más importante es que necesitas comentarios y comunicación. Hable con otros programadores preferiblemente fuera de la organización en la que trabaja. Trate de trabajar con la mayor cantidad de gente posible (OSS es bueno para eso) eventualmente usted aprenderá de personas, no de libros.
Practique programación funcional, tanto en lenguajes de programación funcionales dedicados, como en lenguajes orientados a objetos. Esto aumentará su apreciación de cómo los algoritmos reutilizables ayudan a fomentar interfaces bien definidas, lo que lleva a elementos de programa más fáciles de trabajar.
TDD funcionó para mí. Escribir las pruebas primero sin buena oo es una verdadera PIA, así que tuve que mejorar en eso.
Te vuelves un mejor programador orientado a objetos al olvidar la orientación de objetos por momento y orientarte a escribir programas mejores y más limpios mientras mejoras tus programas existentes.
Un poco de todo. En cuanto a cualquier idioma (programación verbal), cuanto más te expongas, más aprenderás.
Así que lee libros, lee el código de tus compañeros de trabajo. Y, al menos, lo más importante, aprender nuevos lenguajes de programación: ampliarán su visión, lo harán más crítico con su propio código y le permitirán reconsiderar sus hábitos de programación.
Acerca de los patrones de diseño, son una forma estándar de facto de solucionar problemas comunes en los lenguajes comunes. Debe conocerlos para evitar reinventar la rueda y comunicarse mejor con sus compañeros de trabajo, pero también debería verlos trabajando en función de las características que faltan en los idiomas que está utilizando. El patrón de máquina de estado existe solo en los idiomas que no los proporcionan como construcciones internas (no es que conozca un idioma que los proporcione, pero se entiende la situación).
También agregaría:
- siempre refactorice si es necesario y el tiempo lo permite (inofensivo ya que tiene pruebas unitarias para evitar regresiones, por supuesto).
- aprende cuándo evitar la herencia (que es más frecuente de lo que piensas).
- aprende cuándo evitar OO (cuando no agrega ningún valor).
- no confunda OO con encapsulamiento (que es el beneficio principal de OO pero también lo proporcionan otros paradigmas).
conocer y comprender los patrones de diseño de GoF (Gamma et al.) nunca es incorrecto. se pueden aplicar a muchas situaciones. ¡Supongo que son cosas esenciales para cada desarrollador!
probablemente descubras que los elegantes diseños de OO que admiras no son la primera iteración , sino el resultado de varios ajustes, refactorizaciones y ajustes
trata de calificar por qué crees que sus diseños son "mejores" que los tuyos y ajústate en consecuencia
la diferencia entre un escritor aficionado y un escritor profesional es que el profesional reescribe ; lo mismo vale para la programación
Estar bien aconsejado, tener a esas personas que se sientan contigo cuando tienes un problema y trabajar contigo. Obtienes una idea de cómo están pensando en las cosas de una manera OO.
Revisiones de código regulares. Creo que aprendí más de una revisión del código del equipo realizada a través de PowerPoint en la que se derramó algo de desprecio sobre mi código. Concentrado mi mente, lo hizo.
Ayudé por supuesto que aprendí OO con Smalltalk (todos deberían ser forzados a hacer esto en mi humilde opinión). El lenguaje siempre fomentó el concepto de ''envío de mensajes''. Es decir, no incluya las cosas aquí, escriba un nuevo método y llámelo (es decir, envíe un mensaje y obtenga una respuesta **) ¿Resultado? Simplicidad, bajo acoplamiento, alta cohesión.
** Cuando escribo mi JavaDoc para un método de acceso, sigo escribiendo ''answer a [blah] que representa la [cosa]'' La gente puede pensar que soy extraño, pero nadie llamó a la policía hasta el momento ....
De repente, comenzó a tener sentido para mí cuando traté de reducir las dependencias entre las clases, los paquetes y módulos (java), para especificar los límites claros del módulo y para eliminar los ciclos en las dependencias. Especialmente esta eliminación de ciclos me trajo muchas ideas. Sus dependencias de clase / paquete / módulo idealmente deberían formar un árbol.
Que alguien revise tu diseño es bastante importante. Revisar y mantener el código heredado lo ayuda a darse cuenta de lo que hace que el software se pudra. Pensar es también muy importante; Por un lado, no te apresures a implementar la primera idea. Por otro lado, no pienses todo de una vez. Hazlo iterativamente
La lectura regular de libros / artículos, como Model Driven Design de Eric Evan, o el aprendizaje de nuevos idiomas (Smalltalk, Self, Scala) que adoptan un enfoque diferente de OO, te ayuda a comprender realmente.
El software, y OO, se trata de abstracciones, responsabilidades, dependencias y duplicación (o falta de ella). Manténlos en tu mente en tu viaje, y tu aprendizaje será constante.
Se requiere ser un mejor programador para ser un mejor programador OO.
OO ha ido evolucionando a lo largo de los años, y tiene mucho que ver con el cambio de paradigmas y tecnologías como la arquitectura n-tier, la recolección de basura, los servicios web, etc., el tipo de cosas que ya has visto. Existen principios fundamentales tales como mantenibilidad, reutilización, bajo acoplamiento, KISS, DRY, ley de Amdahl, etc. usted tiene que aprender, leer, experimentar y aplicarlo usted mismo.
OO no es un fin en sí mismo, sino más bien un medio para lograr soluciones de programación. Al igual que los juegos, los deportes y las artes, las prácticas no pueden entenderse sin principios; y los principios no se pueden entender sin prácticas.
Para ser más específico, estas son algunas de las habilidades que pueden hacer que uno sea un mejor programador. Escuche a los expertos en el dominio. Sepa cómo escribir pruebas. Sepa cómo diseñar un software de escritorio GUI. Sepa cómo persistir los datos en la base de datos. Capa de UI separada y capa lógica. Sepa cómo escribir una clase que actúe como una clase incorporada. Sepa cómo escribir un componente gráfico que actúa como un componente integrado. Sepa cómo diseñar un software cliente / servidor. Conozca redes, seguridad, concurrencia y confiabilidad.
Los patrones de diseño , MVC, UML , refactorización , TDD , etc. abordan muchos de los problemas, a menudo amplían OO de manera creativa. Por ejemplo, para desacoplar las dependencias de la capa UI de la capa lógica, se puede introducir una interfaz para ajustar la clase UI. Desde el punto de vista puro orientado a objetos, puede no tener mucho sentido, pero tiene sentido desde el punto de vista de la separación de la capa de IU y la capa lógica.
Finalmente, darse cuenta de las limitaciones de OO también es importante. En la arquitectura de aplicaciones moderna, la vista purista de datos + lógica de OO no siempre se adapta muy bien. Objeto de transferencia de datos ( Java , MS , Fowler ) por ejemplo, quita intencionalmente la parte lógica del objeto para hacer que transporte solo los datos. De esta forma, el objeto puede convertirse en una secuencia de datos binarios o XML / JSON. La parte lógica se puede manejar tanto en el lado del cliente como del servidor de alguna manera.
Creo que para un buen diseño de OO uno necesita adquirir la mentalidad adecuada.
No estoy seguro de cuál era la razón detrás de la persona que degrada las respuestas que se refieren a Smalltalk, pero Smalltalk seguramente tiene algo que ver con eso. La palabra clave es metáforas. Para la mayoría de los programadores, y esto se aplica en la mayoría de las ciencias de la computación, las metáforas centrales son mecánicas: mecanismos de relojería o máquinas de vapor.
El esfuerzo más difícil es que necesites reemplazar esta metáfora por otra. No es una metáfora mecánica, sino la metáfora de los sistemas vivos, de las ecologías. Si se ha esforzado por adquirir algún tipo de excelencia en la primera metáfora, esto puede ser realmente difícil e incluso doloroso.
La forma en que todos los objetos en Smalltalk trabajan juntos sigue de cerca esa metáfora. También encontré el libro de Kevin Kelly: Out of Control interesante en este contexto, porque el libro contiene muchos ejemplos de soluciones reales basadas en esta metáfora.
[humor]
Las habilidades orientadas a objetos pueden aprenderse de libros y otros recursos. Pero si tienes suerte, heredas las habilidades de tus padres. La mayoría de las veces es una cuestión proporcionar y usar el método correcto. Tenga cuidado con la cantidad de argumentos. Menos es mejor.
Usa los nombres correctos para cualquier cosa. Use verbos como método de actividad. Use sustantivos para cualquier cosa que necesite ser recordada. No sea demasiado creativo y mantenga su solución lo más simple posible; de lo contrario, sus usuarios serán confusores.
También es importante encapsular los detalles desagradables. Y asegúrese de ocultar sus miembros privados para el público en general, de lo contrario, se producirá un comportamiento inesperado. También tenga en cuenta para captar su situación excepcional en el nivel correcto.
Descansame para presionarlo para que siempre pruebe sus unidades y use la interfaz correcta para proporcionar los controladores suficientes para el usuario feliz.
[/humor]
3 es el número mágico; no menos no más y está en todas partes.
Menor herencia posible al minimizar la subclasificación.
Mucho posible acoplamiento libre al tener objetos independientes.
Quédate en eso
Explicando por muestra.
La interfaz de primer paso es la definición de acceso a su sistema.
interface i { getObject($o); }
- En términos de página web, esta es la URL única o el parámetro.
- En términos de MVC, este es el Modelo.
- En términos de árbol, esta es la conexión (rama) de padre a hijo.
La abstracción del segundo paso es el control de su sistema.
abstract class Controller {
function getObject(){}
function validateObject(){
// o must be a digit
// o must be between 0 and 120
// ... etc
}
}
- En términos de página web, esta es la Validación de los requisitos como el usuario conectado, la base de datos conectada, etc.
- En términos de MVC, este es el controlador.
- En términos de árbol, este es el padre.
El tercer y último paso es un objeto real que debe tejer y cultivar los datos disponibles.
class View extends Controller (InputObject $in, OutputObject $out) {
}
Los datos disponibles en esta clase concreta provienen también de 3 direcciones.
- extiende el controlador
- InputObject $ en
- OutputObject $ out
Este objeto de presentación sería: en términos de página web, el resultado del resultado, el contenido de la página. - En términos de MVC la vista. - En términos de árbol la hoja.
Te recomiendo que pienses en más de estos conjuntos de triángulos. Prueba por ejemplo
- la configuración de los planetas y su comportamiento en órbita dentro de nuestro sistema solar.
- estructura de un automóvil y su comportamiento cuando va a conducir.
- razón y resultado dentro de diferentes estados.
Buen diseño OO:
- se lee como poesía
- no necesita ningún comentario
- confía en tus objetos (deja que el control se vaya)
- favorecer la composición sobre la herencia
Algo que funcionó para mí es la lectura . Acabo de tener un momento Bulb con este libro ... Objeción de objetos de David West, que elabora el comentario de Alan Kay de ''La revolución de los objetos aún no ha sucedido'' . OO es cosas diferentes para personas diferentes. Si lo comparas con el hecho de que tus herramientas influyen en la manera de resolver un problema. Entonces aprende varios idiomas
Personalmente creo que comprender la filosofía, los principios y los valores detrás de una práctica en lugar de imitar una práctica ayuda mucho.