At 11:31 AM -0500 1/20/10, Bob McConnell wrote:
From: tedd

 At 10:26 AM -0500 1/19/10, Bob McConnell wrote:
 Some problems will fit into it, some don't.

 I teach OOP thinking at the local college and haven't run into a
 problem that doesn't fit. For example, in my last class I had a woman
 who wanted to pick out a blue dress for her upcoming wedding
 anniversary. The class worked out the problem with a OOP solution.

Hi Tedd,

Here's one you can think about. I have a box, purchased off the shelf,
with multiple serial ports and an Ethernet port. It contains a 68EN383
CPU with expandable flash and RAM. The firmware includes a simple driver
application to create extended serial ports for MS-Windows, but allows
it to be replaced with a custom application. The included SDK consists
of the gcc cross-compiler and libraries with a Xinu kernel and default
drivers for a variety of standard protocols.

I need to build a communications node replacing the default drivers with
custom handlers for a variety of devices. It must connect to a server
which will send it configuration messages telling it what hardware and
protocols will be connected to each port. The Xinu package includes
Posix threads.

In the past 23 years I have solved this problem six times with five
different pieces of hardware. But I still don't see how to apply OOP to


 Some people can look at problems and see objects and some can't.

 That's for certain -- but in time just about everyone can understand
 the basic concepts of OOP.

Understanding basic concepts and understanding how to map them on to
real problems are two entirely different skill sets. I understand the
concepts, they just don't make any sense to me. All of the definitions
are backwards from the way I learned to evaluate problems. I feel like a
carpenter trying to figure out how to use a plumber's toolbox. There are
some things in there I think I recognize, but most of it is entirely
foreign to me.


Bob McConnell


I am sure that you have all the tools and you solve problems in similar fashion -- it's only the jargon just hasn't made sense to you yet -- but it will. Six months from now , or a year, or whenever -- you'll have your "Is that what you're talking about? Hell, I've been doing that for years- -- but not quite that way" moment.

The problem is to break the problem into smaller and smaller parts that can be solved without requiring any alteration by the outside world. In other words, make the communication between the parts as simple and as independent as possible. They call encapsulation (data hiding) and loose coupling. From that, you can assemble the parts as you like.

I don't know your specific problem, but it reminds of a problem I had several years ago when I was writing software for plotters (Apple, HP, IT, Houston, etc.). Each plotter had it's own internal commands for pen-up/down, move x,y, and so on. While this was before OOP, the solution was to create a universal plotter language and then write translators for each specific plotter. That way, I could use my universal plotter language to do plotter things without ever thinking about any specific plotter.

That way when another plotter came along, I would simply write a routine that would control that plotter's basic pen-up/down and move x,y commands in my plotter language. The technique worked very well. IMO, it was that type of abstraction that launched OOP.

The problem you present is one where I would try to find the commonality between all the components and reduce those down to the simplest aspects of communication and responsibility.

I know that sounds like a bunch of OOP-speak, but problems well defined will expose their solutions.

Leonardo da Vinci was once asked about his marble carvings -- he replied (not a direct quote) that he just carved away everything that wasn't part of the statue. He was liberating the statue from the marble. Similarly, we liberate the solution from the problem.




PHP General Mailing List (
To unsubscribe, visit:

Reply via email to