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
it.
----
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.
Cheers,
Bob McConnell
Bob:
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.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
