Prev: 64 bit date in 32 bit php ??
Next: Iterating ASTs with SPL in PHP-5.3.1
From: Kim Madsen on 20 Jan 2010 10:56
tedd wrote on 20/01/2010 16:11:
> 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.

Don't forget to throw an exception if another woman shows up in the same
dress and color at the wedding! That would make you OOPD crash totally! ;-)

--
Kind regards
Kim Emax - masterminds.dk
From: Paul M Foster on 20 Jan 2010 11:18
On Wed, Jan 20, 2010 at 10:11:18AM -0500, tedd wrote:

<snip>

>
> While I teach OOP, I don't write any OOP for clients. My charge is to
> do things quickly and OOP requires a considerable amount of analysis
> before creating a solution. In most cases, I don't have the time.
> Besides, I'm more of an agile programmer and that doesn't lend itself
> well to OOP, IMO.

This is a fascinating viewpoint. It's almost a sideways condemnation of
OOP: "It takes too long to write OOP for customers". (I know that's not
how you meant it.) But I have to agree, with one proviso. I tend to
write mostly procedural for clients because of time constraints. But I
believe part of the reason I do this is because I haven't built generic
OO components ahead of time which lend themselves to being used on
client sites. If I had spent the considerable time to build OO
components which were usable in this context, I'd be happy to use them.
OTOH, MVC (OOP on steroids) is just beyond reasonable in most cases for
client sites.

I will also echo that it takes a lot of time/work to correctly build OO
components, compared to straight functions or function libraries.

Paul

--
Paul M. Foster
From: "Bob McConnell" on 20 Jan 2010 11:31
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
From: J Ravi Menon on 20 Jan 2010 14:06
Hi Bob,

[Couldn't resist jumping into this topic :)]

Even if you look at traditional unix (or similar) kernel internals,
although they tend to use functional paradigms, they do have a
OOP-like flavor. Example:

Everything in a unix system is a 'file' (well not really with
networking logic, but it is one of the most important abstractions).
There is a notion of a 'abstract' base class 'file', and then there
are different 'types' of files - regular, directory, devices etc... So
you 'instantiate' a specific 'concrete' object when dealing with a
specific file. What are the methods that apply to all files? There is
open(), close(), read(), write(), ioctl() etc... Not all methods are
valid for certain kinds of files - e.g. usually you don't write() to a
keyboard device.

In unix and C, the OOP is modeled using structs (to store various
attributes, or data members), and each struct tends to have
'pointer-to-functions' (listed above in case of files) to actual
implementation on how to deal with such objects in the system.

In fact the device-driver framework in unix can be thought of as an
excellent example of polymorphism where a table stores all the
specific functions that operate on the device.

Grouping data and its associated operations is one of the hallmarks of
OOP. In C, there is no *direct* support to express such groupings
where as in C++ (and other OOP languages), there is direct support via
notion of 'classes' to express such relationships.

I would recommend this book: 'The design and evolution of C++' by
Bjarne Stroustrup where such topics are discussed more in depth.

Hope this helps.

Ravi




On Wed, Jan 20, 2010 at 8:31 AM, Bob McConnell <rvm(a)cbord.com> 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
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
From: tedd on 20 Jan 2010 14:21
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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: 64 bit date in 32 bit php ??
Next: Iterating ASTs with SPL in PHP-5.3.1