> > - easier for other people to maintain even years from now > > - easier to migrate and expand > > - objects make it easier to interface and work with other things, > > consistantly and without much effort > > I agree with what Dan said, but I think it is important to emphasize > the very important side effect the above all lead to: > > - decreased time to debug existing and future problems > > Which directly leads to: > > > - decrease cost( time, money, space, prcessing power ) > > I think many organizations (at least American, it is part of our > culture) when first venturing into a new project look only to the > upfront costs but ignore the cost of maintenance, which over the life > of most projects (at least ones that start off on the wrong foot) > will be substantially higher than the initial development expense. > Code improvement should be cheaper in an OOP environment, but this is > not just for new developments, but includes debugging and testing. It > is a cascading effect, shorten the time to debug, then shorten the > time to fix, which leaves time for new development/improvements which > accelerates the affectiveness of the application.
Agreed.... but most of that can be achieved without objects. We have some sweet but very *STRANGE* C include libraries that do this sort of thing, providing all the normal and expected behavior of an object representing a file, but with a purely functional interface. VERY nonstandard, but effective. A lot of what we're doing *is* new code, tho, because they have a hard time believing it can be abstracted enough to be useful. Why put six lines of code in a module? BECAUSE THEN YOU CAN USE IT WITH TWO! But they just shake their head, and cut&paste, and say "fewer keystrokes". Then I get so sputtering flustered that I can't make a point, and have to just walk away. On the other hand, for complex tasks, one guy does build modules. He just refuses to even look into object technology. I don't want to harass him, but I really do believe there has to be a reason so many people use this model, even though you could design solutions that do effectively the same thing without it. I think the main thing is polymorphism. Code reuse and encapsulation are easy enough using a module with some my() vars. You can even mock up multiplicity with an internal hash, sort of. They say the multiplicity issue doesn't matter for most of what we do (tho it does come in handy when you *can* do it....) But can someone give me good, solid examples of polymorphism that would be hard to replicate in functional code? Then again, I doubt that will convince them either. I can hear it now: "We don't need that." ~sigh~ __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
