Bob McConnell wrote:
[SNIPPED]
the fireman. Going futher, using OOP let's you do all sorts of generic
Hi Rob,
Unfortunately, you still don't understand the problem I have. While it
takes a while to puzzle out the details, I don't have any trouble
reading, understanding or debugging code like this, even though you
skipped completely over several major components (*). I have even
modified existing methods and made minor adjustments to classes, _once
they have been written_.
What I can't do is take a problem description and turn it into classes
that will actually solve the problem. I can usually turn it into
procedures relatively quickly. I can and have built real-time,
multi-tasking and multi-threaded applications on a variety of kernels
and operating systems with no significant trouble. I have written device
drivers, interrupt service routines, message queues and I/O buffering
routines without spending a lot of time thinking about them.
But defining objects and then figuring out how to create and use them
completely escapes me. My mind simply won't map a problem into objects,
it only sees procedures. Even when I look at classes, they resolve only
as loose groupings of functions and variables, not as unified
components.
If anyone knows how to fix that, please tell me. In the meantime, in my
continuing effort to eschew obfuscation, I will stick with procedural
programming.
Bob McConnell
(*) For example, "$this->" suggests you have added an array of pointers.
Some are pointers to functions (aka methods) others are pointers to
variables (aka members). But there is no indication where this array
came from, what it means, nor how it affects the code structure. From
experience I know that "$this->" is not always needed, but the C++ rules
for when it is or isn't are neither clear nor consistent. There are no
declarations nor assignments for it. It simply adds another level of
obfuscated dereferencing that needs to be done in my head to understand
what is going on.
You also failed to explain what "new" does, or "parent::__constructor".
What is the relationship between a class and an object? I get frustrated
because of the extra overhead required to instantiate an object with its
members before they can be referenced, instead of simply being able to
use them at any time from anywhere in my code. Likewise, having to pass
a pointer for one object to another object before the second can call
the first is also counter-intuitive. They're all part of the same
application, why doesn't the compiler take care of those details like it
should?
Bob,
One of the best books that can help attain a practical understanding of
OOP is "Head First Java". Please do not be eluded by "Java" in the title.
I'd sincerely encourage you to borrow "Head First Java" from someone,
and then buy "Head First Object Oriented Analysis & Design".
You'll find answer to most of the questions raised by you, and in pretty
interesting ways.
Obviously, I don't expect answers for these questions, but hopefully
this will give you a better understanding of the greater issues
involved. This is a far cry from the Fortran IV I was taught in college
40 years ago. B.M.
--
Regards,
Bipin Upadhyay.
http://projectbee.org/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
