Presented by Hal Helms.

1. There is a lot of pseudo-OO (affectionately acronymed pOO). What's so bad is that it looks like OO, you have the complexity of OO, but you don't have the benefits of OO.

2. Frameworks and architectures are your friend. Especially the Model-View-Controller design pattern. It is pervasive throughout the industry. Why? Because OO is all about separation. MVC enforces that.

3. Inheritance. How to use it wisely.

4. Beware the guru. Not that they will necessarily give you bad advice; it's just that it hasn't been internalized by you. Don't be afraid to try things and make mistakes. You need to understand why these concepts are good for yourself.

"The opposite of a correct statement is a false statement. The opposite of a profound truth may well be another profound truth." -- Niels Bohr

It's not that procedural programming is wrong. It's just that OO can be better. First of all, it encompasses all the best practices of the pre-OO world. Then, it strengthens these best practices or provides new capabilities. Central ideas behind OO: Encapsulation, polymorphism, inheritance.

When programming, you should personify the code. Thus, you could say object orientation is...

• A way of encapsulating data and behavior in a software construct known as an object.
• Objects have common properties expressed as "I know this about myself.."
• Objects have common methods expressed as "I can do these things.."

So think of methods. Think of objects that just communicate with each other. As an after-thought, what would happen if these objects die, for instance, if the machine was shut down? That's when writing to a database or some other persistence layer comes to play--only as a means to persist the objects. The key is the objects and their methods, not what they contain or how they're stored.

As people, we all are going to go somewhere after this presentation. In the procedural world, you have to get from us our instructions on how to go home, and execute those. In the OO world, you just send me a message, "Nice seeing you; now leave." I then execute that in whatever way I need to do it, and you don't have to be aware of what or how that is.

A component with data and accessors and that's it: Are you really an object? Maybe, technically. But really you're just an irritating structure that only allows access with annoying getters and setters. Real objects should be able to do specialized functionality when asked to do something. Something specific to its identity.

Instead of:

Do something like:

If your CFCs are nothing but collections of functions or wrappers for queries, you're not getting the real benefit of OO.

Model. A domain model is a software representation of your organization. An employee, a customer, an invoice. When you are working in the same environment, your domain model will get richer and richer over time. Components are a great way to implement that.

View. HTML, Flash, Flex, Ajax. Knows nothing of the model.

Controller. Mediates user requests and draws on resources from the model. A "Front Controller", or "Central Controller", is just a controller that will generally mediate all requests of an application.

Inheritance is fun, it's cool. But it is overused. The more you use inheritance, the more dependence your code has, so theoretically it is easier until you start needing to change things, in some cases.