Hey Kunal, > The entire concept of OOP was based on the data and not the processing :)
No, this seems too much of a simplification. In the 'good old days' we used to design a program by using a flowchart. Such is an entirely procedural/code-based approach. Each of the philosophies that followed/developed from there, suggested that we should pay (more) attention to the data (and its structure/characteristics). However none is exclusively "based on the data and not the processing". You need to consider both and not one at the expense of the other... This point was emphasised by an earlier correspondent! > But, no one has yet addressed the core of my question. What do you mean? Here is the original question: ----- does anyone know of any good papers on modular programing? I have been able to make my code modular, but I am not satisfied with it. I am trying to make my program work the "plug in" way.. where i can just add more modules on the fly... any tips? :) ----- Which bits were addressable by someone else, and which parts are very much restricted by knowledge only in your head? The "add more modules on the fly" was such a mixture of terminology/buzz-words as to sound Superman-futuristic!? (include files possibly?) Two suggestions: - do the reading and sort out your approach, then roll forward into the specific application/review its design/modularity etc - address a specific situation (as below) by describing your objectives for it, the necessary parameters, what you have done so far, etc Don't muddle the entire process of LEARNING about a philosophy/approach, with 'fixing' a specific piece of code. How can I make any > application plugable? I am trying to create a standard which will work with > every other language. A simple example of what I am attempting to do is : > I have a guestbook A. I have features in it > a. allow public viewing of records > b. dont allow publiv viewing of records > > Now, this is very simply, I could just store the on/off value and then > validate agianst that. But when it comes to bigger applications, and more > complex situations, where you have to make choices like, allowing the data > to be written to a dbase or no, wether it should get processed or no. How > does one handle such situations? What's wrong with your 'guestbook' solution? If you're not satisfied, start a new conversational thread (ie with a more descriptive title) because there are many experienced 'guest bookers' on the list, who will be more than capable/happy to share ideas/experience. The philosophies behind modular programming, structured programming, and object-oriented programming all unite in the realisation that "bigger applications" and "more complex situations" can be rendered to be collections of smaller and less complex 'units' that can be individually programmed (and tested) as 'simple solutions', and then combined together to provide size, complexity, and power. (and so we're back to doing a bit of reading up on/absorbing the subject!) Regards, =dn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
