quote:Original post by SabreMan
You appear to have been taken by the reuse fallacy! The point I''m making is that you can''t really design for reusability, so you should not put much effort into it. If you design your class to be used in 2 or 3 different applications, then using it in the 2nd and 3rd application does not constitute reuse, as you are putting it to it''s intended use.
lol... maybe YOU can''t design for reusability, but for those of us who take the time to follow a robust OO methodology, it is quite automatic.
quote:
I disagree with the terminology. I suspect they are being used for their originally intended purpose. How is that reuse?
Being used more than once is being reused. What part of that do you not understand? It is pretty simple. Obviously it is being used for its intended purpose. The trademark of a solid OO design is that each object has a specific purpose. But if it is being used in different applications for its intended purpose, it is being reused.
quote:
It is a fallacy, and I believe the s/w world is starting to wake up to it. XP, Refactoring, and the principle of minimalism, for instance, recommend that you build what you need for today, and don''t guess what you might need tomorrow. With the correct architecture it should not cost any more to change your s/w as new requirements become apparent. OTOH, guessing what those requirements might be inevitably leads to wasted effort. It''s not that I''m saying reuse doesn''t exist (apologies if I gave that impression), it''s that I don''t believe it''s a worthwhile pursuit.
LOL... what exactly does XP, refactoring and minimalism have to do with your argument? Refactoring has to do with altering a current design. Very little in the history of programnming has been written more with the intent of facilitating reusability than XP. Hello .NET architecture??? How does this equate in any way to building what you need for today? This minimalism term I am unfamiliar with in reference to software development.
quote:
OOD/OOP saves alot of dollars over procedural programming methodologies.
Is there any proof of this?
Yes there is a whole lot of proof...
quote:
The reason is first of all reusability, second of all is code-to-error ratio which is generally quite a bit lower on AVERAGE (this meaning with your mediocre programmers as well as your elite programmers... obviously there are some procedural programmers that dont make very many errors...) with OOD/OOP projects.
Or this?
Yep...
quote:
Overall, I believe reuse is one of those terms used by management, and it has never really been thought out very well. It sounds good in books and technology brochures; people start using the term without thinking what it means, and they believe they are achieving reuse through some twisted meaning of the word. It''s all part of Money-Oriented Programming.
Hmmm... It appears there is only one person here that is not thinking very well what the term ''reuse'' means. I have no idea where you get your definition from.
Webster.com has two variations of the word:
Main Entry: 1 re·use
Pronunciation: (")rE-''yüz
Function: transitive verb
Date: 1843
: to use again especially after reclaiming or reprocessing <the need to reuse scarce resources>
Main Entry: 2 reuse
Pronunciation: -''yüs
Function: noun
Date: 1866
: further or repeated use
''to use again'' ''further or repeated use''
Which one of these is so hard for you to design for, or what is your definition of reuse if different than these?
Peace,
Geek