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 <r...@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 > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
