Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
The 1 logic is that due to inheritance. But, except that how does Object Oriented Systems helps in reusability? I have read this article below. https://www.drdobbs.com/a-realistic-look-at-object-oriented-reus/184415594 But, this fails to explain exactly how "Being object oriented, reuse became possible".
That is, you can also reuse whatever is written in that article, even if you don't use object oriented system.
Strangely, code reuse is still a useful idea even when the code isn’t being reused.
Most code isn’t reused. Yet code reuse is still a popular idea. Why? Because when you design code to be reused you design code that is self contained. Code that makes sense on its own. Code that makes explicit anything it depends on.
Reusable code is readable code precisely because it doesn’t assume it knows about the world around it. So when you read it, you can ignore the world around it. That’s nice, even if you don’t actually reuse it.
So the next time some clairvoyant coder claims “this code will never be reused” tell them “we still plan on reading it”.
—-
You don't need OOP to follow code reuse. You just need to be formal about any outside needs. No sneaky hidden dependencies. But you can do that in functional or OO paradigms.
Inheritance is just one of many ways to get Polymorphism. Polymorphism only figures into this if you need to allow flow of control to both go into and come out of your module without allowing outside dependencies. You can use polymorphism to invert the dependency. The isolation this allows helps keep your code reusable.
Decomposition helps with reuse simply because it shrinks what would be reused. That is, how much you have to think about at once. Turn one big thing into three little things and you only have to think about (reuse) one of them at a time.
Unit testing can be thought of as an example of reuse. I think of it more as a demonstration of how reuseable your code is. Reusable code tends to be testable code.
Really, the first reuse of code is when you read it. You run it in your head. Here is where a lot of time gets saved because code gets read far more often then it’s written. It’s very nice when what you have to read to understand code is small.
And of course if you’ve achieved reusable code it should be relatively easy to drop it into a new code base and make use of it. Doesn’t mean it’s ready to be in a 3rd party library. It just means the bloody stumps are at a minimum. This is nice, but not the point.
How reusability is achieved is far less important then that it is achieved. Whether you actually reuse it or not, we just want code that’s easy to read.
The 1 logic is that due to inheritance. But, except that how does Object Oriented Systems helps in reusability?
In a very abstract sense - and in consequence not only held true for OOP - every programming paradigm which helps to modularize your codebase helps reusability, independent from the actual content, be it functions, procedures, classes etc. And these units facilitate reusability.
Most important, your work isn't reusable simply because it's object-oriented. Instead, it's reusable because you've taken the time to make it so. ibd.
The point of OOP though is that some people like the idea, having data and functions operating on the data together in one abstraction unit aka an object.
But, this fails to explain exactly how "Being object oriented, reuse became possible".
These units are (in principle) reusable per se.
tl;dr
Having good abstractions and organizational patterns supports reusability.
By factoring into common base classes with differences handed in subclasses, the base class is the home for reused code. OOP directly supports this factoring.
Further, a single operation (e.g. on a base class object) can be split into multiple methods, where one of those methods is meant to be overridden by the specialized subclass, meaning that the others are being "reused" by all the subclasses. This kind of splitting allows various scenarios: subclasses wrapping base class methods (so they can have control before & after base methods); base class methods invoking subclass specializations; both together.
The ease with which this can be done in OOP reduces the temptation to copy & paste common code — thus, reuse, at least within a single program. Part of this ease needs to be compared with approaches in languages that do not explicitly provide for classes and inheritance.
In C, for example, we have at least three options:
(void*) to allow reuse code reuse in generic function, but this subverts the type system,To be clear, the C language offers lots of ways to accomplish reuse.
For motivation why reuse is important, see @CandiedOranges very good answer. Sometimes we strive for reuse between programs — a packaging as a library or service. Other times we strive for reuse within a single program. And still sometimes we simply write readable code that could be reused but isn't.
The main thing about OO isn't reuse, but lowering complexity. That is, if you're doing it right, you can design/manage/maintain bigger systems, and/or maintain a smaller system with less people.
I wrote about the reasons a while back here. The key is not some technical tools OO gives you, like inheritance etc., but more the right thinking associated with it and concepts such as encapsulation.
Would it be possible to do the same with a different paradigm? Probably, but I don't think that's realistic, because even with OO tools, people still don't really think OO to this day.
That being said, I at least learned a couple of things since the time of that article:
