quote:Original post by Anonymous Poster
The whole purpose of having a class, is that it describes one object. If it does that correctly, then you won''t have to rewrite it in your next project( hence you can reuse it!). It''s my experience that if you can''t reuse it, then your class is doing more than it should.

For an example, look at STL classes, or MFC classes, you guys don''t rewrite them over and over again for each project you do.

If you are having problems reusing classes that you create, then either you are writing classes solely for a specific application, which suggests that you are NOT putting much effort into designing for reusability, or you are just designing them poorly.

I have class libraries that I wrote 5 years ago which I am still reusing for different applications. Not EVERY class can be reused of course, but many general purpose utility classes can. Encryption objects, networking objects, math objects, database objects, logging and error handling objects are all easily reusable and will save you an insane amount of time if they are designed for this purpose and you have a high project turnaround. Granted it is a little more difficult to design graphics classes that are reusable, but if you put a little more effort into the big picture, and don''t design for a specific case the first time around, they can be written that way.

One of the encryption classes that I wrote has been used in over 200 applications and considering the complexity of the algorithms has saved on average about 40 man-hours per project over rewriting them. That is a total of 8,000 man-hours. At about $40 per man-hour on average. Thats over $300,000 saved as a result of about an extra 10 man-hours spent designing the module to fit multiple contexts. Fallacy? I don''t think so!

That being said... You have to be wise about what you design for reuse and what you design for specific applications. In a gaming context, if you were going to write some AI code that your unique characters were going to follow in a specific game, and the AI has to be lean and mean, designing for reuse in this case is probably counterproductive. But if you are working for a game company that plans on developing many different 3D games, you certainly would want to design for reusability in the graphics engine. Why would you want to spend 5000 man-hours perfecting a graphics engine for each game that you produce when you can spend 8000 man-hours the first time around for an engine that needs minimal modifications for subsequent games?

No, reusability is not a fallacy and it is a very important aspect of development economics. It is not pertinent to OOD only, but OOD/OOP has more advanced facilities and standards to promote code-reuse. Which is why it is such a popular paradigm in todays world. When it comes down to it, it''s all about the dollars. OOD/OOP saves alot of dollars over procedural programming methodologies. 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.

Peace,
Geek

C++ is not an OO language. It''s a multi-paradigm language that supports aspects of the OO paradigm, but it''s not a terribly great example of OO features. But just because one claims to know C++ and classes, that doesn''t necessarily mean that he or she knows a single thing about OO. And, of course, OO can be applied in any structured language (though it helps proportionally if the language has OO features).

Often, with large projects, OO must be combined with other models (such as the Model-View-Controller model) to be effective and not cumbersome.

quote:Original post by supergeek2k
If you are having problems reusing classes that you create, then either you are writing classes solely for a specific application, which suggests that you are NOT putting much effort into designing for reusability, or you are just designing them poorly.

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.

quote:
Encryption objects, networking objects, math objects, database objects, logging and error handling objects are all easily reusable

I disagree with the terminology. I suspect they are being used for their originally intended purpose. How is that reuse?

quote:
One of the encryption classes that I wrote has been used in over 200 applications and considering the complexity of the algorithms has saved on average about 40 man-hours per project over rewriting them. That is a total of 8,000 man-hours. At about $40 per man-hour on average. Thats over $300,000 saved as a result of about an extra 10 man-hours spent designing the module to fit multiple contexts. Fallacy? I don''t think so!

So, if you designed it to fit multiple contexts, how is using it in alternative contexts reuse?

quote:
No, reusability is not a fallacy and it is a very important aspect of development economics.

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.

quote:
OOD/OOP saves alot of dollars over procedural programming methodologies.

Is there any proof of this?

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?

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.

quote:Original post by Anonymous Poster
The whole purpose of having a class, is that it describes one object. If it does that correctly, then you won''t have to rewrite it in your next project( hence you can reuse it!). It''s my experience that if you can''t reuse it, then your class is doing more than it should.

I''m intrigued with this "if it does that correctly" assertion. I''ve heard it said lots of times, and I find it naive. It''s precisely the principle which I disagree with, since the notion of "correctness" changes depending on the context in which the class is being used. You can''t possibly predict what requirements a future user of your class may have, so it is best not to try and incorporate them on a "best guess" basis.

quote:Original post by Anonymous Poster
For an example, look at STL classes, or MFC classes, you guys don''t rewrite them over and over again for each project you do.

Well, some people do! Anyway, the point here is that using, say, a vector to store a dynamic array of int''s is using vector for the intended use. I also don''t think the STL is a good example, since the people that worked on it, and the time and effort put into it, are not representative of a regular programming team.

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.

Yes you can, if a class is designed correctly, and you see the need for that class in the next project you do, then you should be able to take that class and drop it in with no problems. If you can''t then the class was designed wrong and is probably to cohesive.

quote:Original post by SabreMan
I disagree with the terminology. I suspect they are being used for their originally intended purpose. How is that reuse?

It''s reuse because it''s used in a different application.

quote:Original post by SabreMan
So, if you designed it to fit multiple contexts, how is using it in alternative contexts reuse?

Because he didn''t have to rewrite the class again. He spent time making sure the class was written correctly the first time. Not only does he not have to rewrite it, he doesn''t have to debug it, because it went through Q/A in the first project.

quote:Original post by SabreMan 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.

I agree that guessing requirements for the future might be a waste of effort. If you write a class, and it works, and your next project can use it, then why rewrite it? Most classes should be able to be reused, because they represent an object.

quote:Original post by SabreMan
Is there any proof of this?

Tons, OO if done correctly is far easier for programmers to manage and maintain that procedural code. People aren''t using OO languages just for fun.

quote:Original post by SabreMan
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.

It''s sounds good because it works, it saves money and time. Why rewrite something, when it''s already written, and tested? It sounds like you do a lot more work than is necessary.

quote:Original post by SabreMan I''m intrigued with this "if it does that correctly" assertion. I''ve heard it said lots of times, and I find it naive. It''s precisely the principle which I disagree with, since the notion of "correctness" changes depending on the context in which the class is being used. You can''t possibly predict what requirements a future user of your class may have, so it is best not to try and incorporate them on a "best guess" basis.

I''m sorry but I find your comments very naive. When you design a class to do something, it should do that and only that. Hence it does that correctly. When the next project comes along, and you have need for that something again, then you should be able to use the same class. If you don''t need it, then don''t use the class. It''s that simple. I agree you can''t predict everything. Sometimes you can even inherite from that old class, and add a new interface. You still saved yourself a lot of time, and trouble, and you reused the code!

quote:Original post by SabreMan
Well, some people do! Anyway, the point here is that using, say, a vector to store a dynamic array of int''s is using vector for the intended use. I also don''t think the STL is a good example, since the people that worked on it, and the time and effort put into it, are not representative of a regular programming team.

Exactly, using it for its intended use, but its reuse, because it''s being used in different programs! STL is an excellent example, so is the Java language. If you take a little time in your design of your classes, you will be able to reuse them if need be. You don''t have to predict the future, just don''t make your classes to cohesive, and make sure they do the one thing they are suppose to do!!!

quote:Original post by Anonymous Poster
Yes you can, if a class is designed correctly, and you see the need for that class in the next project you do, then you should be able to take that class and drop it in with no problems. If you can''t then the class was designed wrong and is probably to cohesive.

This is nonsense. How do you know what the requirements are for the next project you do? If you don''t know them, then you can''t guess what "designed correctly" means to that project. Sure, you might get to take the class and "drop it in", but that''s simply good fortune. You can''t plan on good fortune arriving too often.

quote:
It''s reuse because it''s used in a different application.

So, that''s your definition of reuse? If something is designed for multiple applications, then using it in those applications is *use*, not reuse. But, I''m repeating myself.

quote:Because he didn''t have to rewrite the class again. He spent time making sure the class was written correctly the first time. Not only does he not have to rewrite it, he doesn''t have to debug it, because it went through Q/A in the first project.

See above. You can''t know what "written correctly" means for a potential future use.

quote:I agree that guessing requirements for the future might be a waste of effort. If you write a class, and it works, and your next project can use it, then why rewrite it?

Sure. But that falls into the "luck" category. It also requires you to know that the class exists. If you wrote it yourself, there''s a pretty good chance you know it exists. Otherwise, the chances are a lot lower.

quote:
Most classes should be able to be reused, because they represent an object.

Huh? A class written in a single context should represent the blueprint for how objects of that class will act in that context. Once the context changes, the class definition may no longer be correct.

quote:Tons, OO if done correctly is far easier for programmers to manage and maintain that procedural code.

So, if there''s tons of proof, you''ll be able to cite.

quote:People aren''t using OO languages just for fun.

And people aren''t researching beyond OO just for fun, either. I suggest you reserve judgement until you have learned something about some of the new techniques on the ascendant.

quote:It''s sounds good because it works, it saves money and time.

Maybe it does, maybe it doesn''t. There is no empirical evidence. I''ve spent a lot of time on comp.object, and I''ve seen no proof. Not that I dislike OO. I find some of it very useful. However, I also find some of it to be marketing hype. Reuse falls into the latter category.

quote:
Why rewrite something, when it''s already written, and tested?

Sure. If it''s what I need.

quote:It sounds like you do a lot more work than is necessary.

No. I do exactly as much as is necessary and no more. It sounds like you need to go "beyond OO".

quote:Original post by SabreMan This is nonsense. How do you know what the requirements are for the next project you do? If you don''t know them, then you can''t guess what "designed correctly" means to that project. Sure, you might get to take the class and "drop it in", but that''s simply good fortune. You can''t plan on good fortune arriving too often.

You don''t know the requirements for the next project, I never said you did. Sometimes it is good fortune, I never said that when I write my classes, I make sure that they''ll be able to be used in every single project I work on from now until the day I die, and then my kids will be able to use them and pass them onto my grand kids and so on and so on. The whole point is, if you need to represent an object and it''s behaviour in a project, and someone else has already done that in another project, then why shouldn''t I use that code?

quote:Original post by SabreMan So, that''s your definition of reuse? If something is designed for multiple applications, then using it in those applications is *use*, not reuse. But, I''m repeating myself.

If it was written once, and used in different projects, then it''s being reused. What''s so hard to understand about that?

quote:Original post by SabreMan See above. You can''t know what "written correctly" means for a potential future use.

Yes you can, if my class does what it''s suppose to do, and I need something to do that in another project, and I''m able to drop the class in, then it''s written correctly. Why do you assume that your classes should be able to do everything and a bag of chips. I think you are giving your classes to broad a vision. They should be able to do one thing, and one thing well.

quote:Original post by SabreMan
Sure. But that falls into the "luck" category. It also requires you to know that the class exists. If you wrote it yourself, there''s a pretty good chance you know it exists. Otherwise, the chances are a lot lower.

Yes it''s sometimes luck. Most professional dev shops do code reviews, where you should be able to see what people are up too. If yours doesn''t, then I highly recommend you start checking out what your coworkers are up too. It can help out a lot, not only will you learn from them, you''ll be able to understand the product your working on more, and you''ll have some clue of what''s going on when q/a knocks on your door.

quote:Original post by SabreMan
Huh? A class written in a single context should represent the blueprint for how objects of that class will act in that context. Once the context changes, the class definition may no longer be correct.

That''s fine, in that case you are looking for something different.

quote:Original post by SabreMan
So, if there''s tons of proof, you''ll be able to cite.

Look at any dev shop that uses OO, we reuse our classes at my dev shop, it saves us time, it saves us money. If you want a big example, look at Windows, [sarcasm]I''m sure they completely rewrite everything from the ground up with each new release of Windows[/sarcasm]

quote:Original post by SabreMan
And people aren''t researching beyond OO just for fun, either. I suggest you reserve judgement until you have learned something about some of the new techniques on the ascendant.

People will always be researching for new and better things. They researched OO when everyone was doing procedural. mmmh I wonder why that is? Until the new techniques become available to the public, I''ll continue to use my OO because it''s the best thing we''ve got!

quote:Original post by SabreMan
Maybe it does, maybe it doesn''t. There is no empirical evidence. I''ve spent a lot of time on comp.object, and I''ve seen no proof. Not that I dislike OO. I find some of it very useful. However, I also find some of it to be marketing hype. Reuse falls into the latter category.

It does! Just because you don''t reuse, doesn''t mean it doesn''t save money and time. You speak of marketing hype, what prevents your new techniques from falling into the hype? There''s no evidence because you can''t find it in a news group? That is very naive. You should ask people working in OO dev shops, you''ll find your evidence there.

quote:Original post by SabreMan
Sure. If it''s what I need.

that''s the whole point, if you need it, use it!

quote:Original post by SabreMan No. I do exactly as much as is necessary and no more. It sounds like you need to go "beyond OO".

Beyond OO to what? A new technology that hasn''t been implimented yet? Sure boss, I wrote my stuff in this new technology. It will work eventually, you''ll see. Or should I go beyond to procedural again?

quote:
For an example, look at STL classes, or MFC classes, you guys don''t rewrite them over and over again for each project you do.

Yeah, and nobody rewrites the standard C library for every project, either—certainly no more so than, say, the STL.