> and still write maintainable, testable, extendable and configurable code.
"reusable"... reusable code? That was the original point of OOP.
After a few years being a believer n the late 90's as a C++ Ubermensch, I had the horrible realization neither I nor anyone else would reuse any of the classes I had given beautiful interfaces to, and carefully documented. Any time I spent planning for reuse I might as well have spent staring out the window.
Of course who needs to reuse your own classes when you have the huge canker Boost you can drag around with you from task to task.
When I was doing hardware in the 80 early 90's I came to the conclusion that the 'reusable code' fans were all missing a point.
You are either writing a library,a framework, or something like that. Or you are implementing some 'business logic'
The point of the former is reusability. The point of the latter is utterly not and you should not waste your company's time and money or worse let schedules slip because of it.
Some further thoughts over the years.
Reuseable code must have a public, well designed, sable, and documented API or it won't ever be reused. Be honest how many programs are going to reuse this code? Enough to justify all the above? Didn't think so.
One of the problems with reusable code is dependencies. OOP code bases tend to have more than the ordinary number of dependencies.
To practice OOP, its approach is every class should be a "library". Procedural code that doesn't have a class context is felt to be a shameful throwback to an earlier era degenerate C practices. From before some people feel they starting writing "good C++" apparently.
I think having done hardware first gives me a slightly different perspective. Hardware designs get reused a lot, but usually not as a drop in, it gets reworked at each reiteration. Either that are it's something you buy off the shelf in which case the design interface is absolutely stable. Think a uP chip or core. They'll fix bugs and shrink the die, but they never ever change the abstract design. You can still by 8051 cores and IC's and that design has not changed at all in 40 years.
Compare with business logic. The problem is the spec and use case keeps moving. Moving way too fast to be a good library or a framework.
I did not mention reusable anywhere in my comment. If you are writing code to be reusable, you are writing a library and in that case you better make sure that it is a separate project or module so no caller-specific details are leaking into your library.
>>> maintainable, testable, extendable and configurable
but not reusable. I'm not blaming you, or disagreeing... C++ didn't produce reusable results for me either.
I dunno what you were doing 20 years ago, but I was doing this... there wasn't any problem with the classes being unclean or the boundaries cut in the wrong place. It was simply I was almost never going to use those classes a second time. If they had been C functions, I would not have needed them a second time, either, almost always.
After a year or two I realized that being the case, the entire loving OO encapsulation of then was not simply worthless but an active waste of time. And I went back to C.
If you get value from other C++ things that make it worth paying the price, that's great. But file away for a possible future horrifying 3am realization, perhaps nothing is worth the price of a gyre like boost, and just writing it in high quality C may be a better answer.
"reusable"... reusable code? That was the original point of OOP.
After a few years being a believer n the late 90's as a C++ Ubermensch, I had the horrible realization neither I nor anyone else would reuse any of the classes I had given beautiful interfaces to, and carefully documented. Any time I spent planning for reuse I might as well have spent staring out the window.
Of course who needs to reuse your own classes when you have the huge canker Boost you can drag around with you from task to task.