POO o cómo programar orientado a objetos

Yo recomiendo los siguientes libros:

Object-Oriented Software Construction19 --> Todo sobre qué es un objeto y cómo programar en base a ellos.

Head First Design Patterns13 --> Está muy bien para aprender patrones de diseño y a su vez repasar y aperender conceptos de POO.

Practical Object-Oriented Design in Ruby2 --> Aunque no sepas Ruby es muy útil por el enfoque dado y claridad de las explicaciones.

Hola @RebeldeCuantico,

¿te refieres a que en general a mucha gente la faltan conocimientos básicos/intermedios de POO?

Lo he pensado alguna vez, a veces el nivel es demasiado alto para la gente que está intentando salir del lado oscuro y eso puede ser una barrera. Quizás deberían montarse más cosas con la idea de dirigirse a ese público que está muy perdido y necesita empezar con afianzar conceptos más básicos, una especie de mentoría global.

A mi me encantan los videos de Clean Coders14, eso sí

(Disclaimer: estoy todavía en el medio del largo camino de aprender DDD y paradigma funcional)

Bueno, DDD no tiene pq significar solo orientación a objetos. Se puede aplicar DDD con lenguajes funcionales:

• https://fsharpforfunandprofit.com/category/DDD/6
• https://fsharpforfunandprofit.com/ddd/2
• https://pragprog.com/book/swdddf/domain-modeling-made-functional2
• https://www.manning.com/books/functional-and-reactive-domain-modeling3

Y recordad que la parte más importante de DDD es la estratégica, no la táctica.

Salut,
Vicenç

Claro DDD no tiene por qué estar ligado a la POO.

En mi humilde opinión, muchas veces se puede detectar falta de conocimientos de POO cuando las clases no representan "cosas" del negocio. Y digo cosas con toda la intención. cuando los objetos representan procesos y no elementos con identidad propia del negocio, algo falla.
No sé si me explico. Por ejemplo, en mi opinión, una clase CRUD, como regla general, por mucho que tenga la palabra "class" en su declaración, no es verdaderamente un objeto. No tiene estado, no es elemento del negocio, no tiene lógica interna más que agrupar funciones que permiten modificar objetos que están fuera del objeto CRUD en sí mismo.

Tanto es así, que en mi opinión, tiene mucho más sentido utilizar una aproximación funcional para el diseño del negocio (reglas, procesos, etc.) mientras se mantiene una aproximación de POO para crear los verdaderos objetos de negocio. Es decir, POO para la capa de "objetos del dominio" y funcional para la capa de aplicación.

Puede parecer raro y incluso no tener demasiado sentido pero si ligas estas ideas con conceptos básicos de DDD o de arquitecturas del estido de ports and adapters, en mi opinión empieza a tener sentido.

Relacionado con esto: http://blog.koalite.com/2016/11/mitos-y-leyendas-sobre-metodos-estaticos/11

Completamente de acuerdo con los camaradas que mencionan el tema de que se puede hacer DDD son OOP. No recuerdo de qué forma lo mencioné en el podcast, pero me refería al escenario en el que se hubiera decidido usar un lenguaje orientado a objetos, claro

Y muy importante lo que comenta @vgaltes, creo que la parte estratégica es de lejos la que más valor aporta en DDD

Genial reflexión! Esto es algo que me llevo preguntando desde hace tiempo. Cuando hablan de excelencia técnica, qué se supone que significa eso?
Es decir, mi duda surge cuando ves a alguien que domina mil frameworks, te cita las bondades de todos los clouds con sus pros y contras, o implementa 300 patrones para hacer un método que sume 2 números..., pero cuando hace una kata, tipo como la famosa bowling, y se pierden en el primer caso...
En mi opinión, prefiero que quizás no conozca tantos frameworks y demás, pero haga diseños de base que sean auténticas obras de arte. Me da la sensación de que a veces nos centramos tanto en la solución (a través de herramientas) que nos olvidamos del problema y de que surja la solución de forma natural (sí, me refiero al diseño emergente)