0

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.

4
  • 5
    It's worth noting that article was published in 1998, probably around the zenith of object-oriented cure-all-ism. OO programming certainly wasn't the first, nor the last or only, approach to "reuse". – Steve Sep 26 '20 at 11:39
  • @Steve: it is even worth noting the article does not state much about object-orientation as a factor for sucessful reuse, quite the opposite. It seems most of what was written there in 1998 is still valid today. – Doc Brown Sep 26 '20 at 15:18
  • Many software teams will write code to be used in at least two places (regardless of paradigm) -- firstly in the system being developed, secondly by the automated tests which enshrine the requirements and protect against regression issues. – Ben Cottrell Sep 26 '20 at 15:32
  • @DocBrown, oh I agree the article remains valid. But if anyone were to note the blatantly object-centric tenor of the article and ask "what's so special about objects?", which is more or less what the OP does ask, then the most straightforward explanation is simply to consider the era in which the author was writing. – Steve Sep 26 '20 at 18:30
5

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.

3
  • Worth mentioning: running in test fixtures is a kind of reuse. Resusable code is testable code. – Alexander Sep 26 '20 at 17:31
  • @Alexander-ReinstateMonica better now? – candied_orange Sep 26 '20 at 17:58
  • Yep! You already have my upvote :) – Alexander Sep 27 '20 at 0:04
2

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.

0
1

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:

  • We can do OOP using a methodology that requires more verbosity, and the discipline to use it (without the same support provided by language constructs and compiler error messages as with an OOP language)
  • We can do cast to (void*) to allow reuse code reuse in generic function, but this subverts the type system,
  • We can copy & paste code, which doesn't subvert type system, but doesn't reuse code and makes us copy & paste both bugs and bug fixes..

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.

0

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:

  • Inheritance is pretty tricky to get right, so avoid if at all possible.
  • Reuse is grossly overvalued. Reuse has its place in libraries, where the functionality is clearly and cleanly separate from the "business". Like http clients, logging, etc. It has no place at all in business code. I write my objects to work in the given project for the currently given function, not more.
  • Code becomes much more readable if it is less abstract, especially if that abstraction is needlessly added for "reusability", not because of actual requirements.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.