philduba.com

- OO is not a band-aid or a panacea. It really makes one think about what they are trying to build and how to build it
- OO helps in managing complexity to give us maintainable complexity. Change is inevitable, OO helps to alleviate the issues commonly found in complex systems when making changes.
- In looking at OO, remember that it involves both the objects interface and its implementation. Too many just concentrate on implementation
- In OO world, objects are all about behavior, unlike in procedural world where it is almost micro-managing data and passing it all around
- Must concentrate on the objects sending and receiving messages, not on the data structure and/or usage within the object itself, the goal the object is intended to accomplish
- Finds in CF that there is a tendency to look at the persistent layer, matching objects to that persistence setup (whether one to one on tables or compilations thereof).
- Talked about how in his Java for CFers class, he restricts his methods to six words or less. While CF is more verbose as a result, a limit of, say, 15 lines.
- Two commandments of programming - open/closed principal.
- preferential of aggregation (composition) over inheritance
- inheritance is more brittle in its implementation
- Use design patterns. Not much more information needed than that
- Bundle components behind facades, separation of like components, almost module like, plug-in-play, etc. Separation of work, provides API, separates implementation from interface (hmm, I see a theme here).
- Coding standards (not just for OO, but should be for everything) - I could not do the picture of seal and related pun justice
- Don't confuse Java with Object Oriented. Don't try and match what one would do in Java with what CF has/offers and vice-versa.
- Approach development systematically, start with UI, move to messaging, do not start with database and/or persistence
- Don't force everything into an object. Within ColdFusion, not everything fits.
- Not a big fan of ORM. Database schema should not drive the object design and/or properties. Wrote his own way for the objects to create their own tables, sql, etc.

Overall, as far as OO Best Practices goes, he suggests to go back to the basics every now and then to make sure we aren't tying our OO knowledge to frameworks and their implementations.