Re: Smarty Tips and Techniques

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/