The object in question
For all the talk of object oriented design and patterns on this blog I sometimes question my own take on objects. What are objects? What are their roles?
Most of my experience in the professional realm has been in ‘enterprise architecture’ (until recently) where layered approaches are king. Most the systems I have worked on and even designed concentrated on distributing layers, database layers, business object layer, presentation layer, and UIs (views). With this approach objects besides the aforementioned layers act as simple data types (or data transports). They tend to by strongly types and are not really aware of the state they carry. It is the business object layer or presentation controllers that are aware of the objects states. The ‘enterprise’ layer approach even through objects and classes are involved it seems more like functional programming where data types (often referred to as domain types) are defined.
What about the other style of objects where they encapsulated and operate on their own internal representation?
I have recently been working on an implementation of a non-collectable card game and it has brought the questions I have to the forefront. With the PHP CodeIgniter framework, which I am using to implement the game, the controller deals with the model and the view indirectly through load method calls and operate on function defined in both layers. Most examples I have seen of the framework in action use simple arrays to communicate data from the database and view. I am attempting to use objects that contain state as the glue between the interfaces. This falls more in line with my experience and not a classical view of objects. I have often believed that this was a better approach to separate areas of concern when a database changes the code for that interface is one place versus spread across a high number of objects.
Is the classical view flawed? When is it appropriate? When is it beneficial to use a classical object approach?
