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?
Does every cloud have a Chrome lining?
I finally downloaded Google’s new browser Chrome. I had intended too the day it was released and procrastinated it for two more days. I downloaded it last night and have been playing with it off and on since then.
What does Chrome mean for web developers? For one thing it means that all development will need to be testing in yet another browser. One of the biggest pains in web development is programming in such a way that sites and page behave consistently across all browsers that support different standards of the same technology [cascading style sheets [CSS] is a good example of this).
On the positive side chrome has some nice built in features like the browser has a nice element inspector built in that seems pretty solid. It behaves almost exactly like the plug-in FireBug for FireFox, which is an invaluable tool for debugging pages and seeing how other implement the presentation of a page. Since Chrome uses a multi-thread approach to the implementation, each tab has its own memory space and process, it has a built in ‘task manager’ feature (just like Windows OS Task Manager) that allow viewing a pages performance in the browser. It will be exciting to see future features designed to make a web developers life easier.
From a user perspective I think the browser is awesome. It is fast, clean, and sleek. I really like the address bar behaving like a command line, a search box, and an intelligent history … clearly a brilliant idea to give it the user more power. You can drag and drop tabs into their own windows, can recover accidently closed tabs, and much more. I personally look forward to seeing the impact this beta browser will have on the browser market all together. They are certainly pushing the envelope.
