Objects abound us. There are objects that move, objects that are fixed. Objects that reside within other objects and objects that contain other objects. Objects crawl, eat, defecate, breed and die on the surface of other objects. Objects revolve in systems around other massive objects. What about thoughts, concepts, feelings? What about light, gravity, water, the wind? We can consider these objects as well.
So everything is-an Object (reminds me of a very popular programming language). Of course the term object is just an extremely general way to classify things. Software design involves the discovery and classification of objects that reside within a domain, and the creation of objects that serve to frame and facilitate the domain objects.
Object-Oriented Design is a tool and as a tool it has a very specific function. There is an old cliche, "if you have a hammer, everything looks like a nail". But everything is an object, therefore everything is-a nail, in this sense.
Certainly if we name an element in our domain or system, we are speaking of objects. A very powerful naming technique is the use of metaphor. Successful metaphors surround the geekosystem. We don't invent new words, we overload the ones we already have. Words like 'file', 'folder', 'menu', 'icon'. Objects, every one of them. We even overload verbs, for example, 'browse', 'click', 'surf'. One new verb that comes to mind is to 'google'. One 'googles' when at Google. Google is a service (metaphorically speaking), a service is an object.
'Naming' and the use of metaphor is a very important capability for software developers. I think we tend to underestimate the power of well-crafted names and metaphors. The word 'object', with regards to software development, is a great name. The term was coined in the 1960s and is still effective, relevant, and a source of mystery.
The power in the name 'object' comes from the abstract, vague and nebulous nature of the name. By under-specifying what an object is, by allowing the term 'object' to breath, we give 'objects' great capability. So lets go the whole nine-yards and say that everything is an object. Its true anyway.
Its important to be able to live in the abstract, but every now and again we need to touch concrete. The typical way to teach OO is to provide concrete examples and to provide simple tenets such as 'an object is data and the methods that work with the data'. Objects live along side electron-clouds and Heisenberg. Too much concrete - too much uncertainty. I think most of the break-throughs in OO came from the early pioneers (SmallTalkers) who didn't have rules and concrete. They just created. And speaking of clouds, kind of makes you wonder if Grady Booch was on to something with his form of OO design notation. At least he gave Heisenberg his due.
Wednesday, February 23, 2005
Wednesday, February 16, 2005
Graphs and the Space-Time Continuum
I was given a small hammer when I was just a wee lad. With hammer in hand, I wandered my home searching for something to fix. Later, my father had to retrace my steps with wood-filler and paint, repairing various door-frames, sills and mouldings. I don't do much with hammers anymore, the tools of my trade are software technologies. When I learn something new, its like getting a new tool and I go in search of an application. This approach is little non-optimal but it is how I learn. My latest interest are the data-structures known as graphs. Like most software engineers, I learned about graphs in school. Graphs are connected networks of nodes. One of the key points is that the connectivity of nodes is established by having nodes refer to other nodes.
I have never worked with anyone who has ever had the need to create a graph, including the Binary Search Tree. Today, most languages have built-in data-structures such as lists, hash-tables, and vectors. Data is modeled and stored in a database. It is easy to consign the graph to the realm of academia and the exotic. As others discount the graph, I may find a way to use it to my advantage, to make it a permanent part of my toolkit.
To begin, I close my textbook and strap myself into my rocket and launch to low earth orbit. Now adrift in vacuum, away from code examples and technical detail, I once again view the graph. Ignoring the obvious, such as computer networks, air travel routes, and state-machines, what do I see? Anything that interacts with anything probably is a graph. One of my favorite tools is Object-Oriented design. Interacting objects are more exciting to me than functional flow. Interacting objects are nothing more than nodes in a graph.
Can I enhance my ability to model the world with OO by thinking in terms of graphs? Will graphs add a new perspective to my ability to analyze?
Next I dock with my star-ship and warp out of the solar-system. I subject the graph to various experiments. One thing to note is that a graph can exist in three dimensions. Perfect examples are Tinker Toys and Connects. But 3-D graphs can be squashed flat and still exist in 2-D. Therefore it is easy to surmise that graphs of many dimensions exist and can be represented in just two dimensions. Infinity in two dimensions.
Now I launch the graph at the event-horizon of a black-hole. As the graph compresses, the intent of each node become distorted. Yet the relationships remain. The differences between each node becomes less as they merge to a singularity and become one. One node associated with itself. With trepidation, I leave the void, with the memories of that brave graph emblazened in my mind. I return home, reopen my textbook and begin my journey anew.
I have never worked with anyone who has ever had the need to create a graph, including the Binary Search Tree. Today, most languages have built-in data-structures such as lists, hash-tables, and vectors. Data is modeled and stored in a database. It is easy to consign the graph to the realm of academia and the exotic. As others discount the graph, I may find a way to use it to my advantage, to make it a permanent part of my toolkit.
To begin, I close my textbook and strap myself into my rocket and launch to low earth orbit. Now adrift in vacuum, away from code examples and technical detail, I once again view the graph. Ignoring the obvious, such as computer networks, air travel routes, and state-machines, what do I see? Anything that interacts with anything probably is a graph. One of my favorite tools is Object-Oriented design. Interacting objects are more exciting to me than functional flow. Interacting objects are nothing more than nodes in a graph.
Can I enhance my ability to model the world with OO by thinking in terms of graphs? Will graphs add a new perspective to my ability to analyze?
Next I dock with my star-ship and warp out of the solar-system. I subject the graph to various experiments. One thing to note is that a graph can exist in three dimensions. Perfect examples are Tinker Toys and Connects. But 3-D graphs can be squashed flat and still exist in 2-D. Therefore it is easy to surmise that graphs of many dimensions exist and can be represented in just two dimensions. Infinity in two dimensions.
Now I launch the graph at the event-horizon of a black-hole. As the graph compresses, the intent of each node become distorted. Yet the relationships remain. The differences between each node becomes less as they merge to a singularity and become one. One node associated with itself. With trepidation, I leave the void, with the memories of that brave graph emblazened in my mind. I return home, reopen my textbook and begin my journey anew.
Subscribe to:
Posts (Atom)