Logistics of code reuse (OOP)

Question

One of the driving points behind OOP is code reuse. I am curious about the actual logistics of this and how others both in team or solo handle it. For example lets say you have 5 projects you have worked on and between them you have a ton of classes that you think would be useful in other projects.

How do you store them? Are they just in the normal project repository or do you break out the relevant classes and have them (as now copies) in another unique source repository that only houses code pieces that are intended to be reused?

How do you go about finding or even knowing that there is a good piece of code out there that you should reuse? It's easier if your solo because you remember that you have coded something similar but even then it becomes kind of a stretch.

If there is some way that you are storing these pieces of code do you then also have them indexed and searchable by tag or something. I fear that it just boils down to some tribal knowledge that you just know that for situation A i need solution B and we have a good piece of code that already can help here.

A bit verbose but I hope you get what I am aiming at. If you think of a better way to make the question clearer please have at it :)

TIA!

Answer 1

I don't share "objects" between projects, I share classes which define the objects.

How it's done varies: Sometimes I build a compiled library with commonly shared classes that are related to each other. Sometimes I manually copy the files between projects, if it's only one or two files and much less likely to be reused again - though if I do this more than twice I usually start wondering if I should add those classes to an existing library or make a new one.

How do I find code that can be re-used? I have to know the project. For very large projects that have been worked on for years by numerous developers, yes it has happened once or twice where I start creating new functionality only have have it pointed out to me that it already exists. How "discoverable" the preexisting functionality is really depends on the earlier developers and how well they documented what they did. The better the documentation, the less likely it is that someone will later fail to find the pre-existing classes.

Answer 2

Reusable classes of a company are just like any other vendor library and should be treated the same way. The only difference is how new versions are created.

If a project that is using that library discovers a bug there, or the project simply needs a new feature that would make sense to be there, then the code of the library can be changed locally in the project.

Later, when the change is running smoothly again, a new version of the library can be generated, by applying all the needed changes to the repository of the library.

At this point the new version should be published to all developers in the company such that they can decide wether to update any project that uses an older version.

In my PHP projects for example, that library is stored as a sibling of the Zend Framework library in the library/vendor directory and it shares the same naming convention such that the same autoloader can be used for both.

Answer 3

Depends on the shared code really.

If it is common functionality which is general and could be useful to various projects such as how to handle file uploads or how to measure distance between points. Or common operations such as String manipulation or common data structures such as a concurrent asynchronous queue. Then I believe the preferred method would be to take it out as a different project and build a common library.

Some notable Java examples can be found on many big projects, for instance:

• Apache commons are used by many different projects.
• Guava is used in many places in Google.
• Twitter commons is what twitter use across projects.

There are many such examples...

If on the other hand the reused code is much more specific, as in a Servlet which does authentication and interfaces with your companies propriety protocols. I would recommend modularization of the 5 projects so that they depend on the same sub-project and in your own development environment you can keep whatever projects you want checked out and just have them reference each other (simple with most modern IDEs).

So in the second case you would have (I'm using java jars but it'll be the same for anything):

 + project1.jar
 + project2.jar
 + project3.jar

And you would change it to be:

 + project-core.jar
   |- project1.jar
   |- project2.jar
   |- project3.jar

Answer 4

1) First, Code reuse is not an end on itself. Remember that code reuse implies increased dependency. if the code being reuse is not stable (meaning that features or fixes are being still added to it) it means that it might affect all places that depend on it

2) If a piece of code is not written from the beginning with reusability in mind, its very unlikely you will be able to isolate it back.

3) a reusable component should have little or no external dependencies. It should have its own test suite, i should be able to download/check it from repository, build it and run the test suite on its own

So its a bit more complicated that just reusing some classes in other projects, if you are doing it, you cannot do it half-heartedly; you need to go all the way down. If you "reuse" by copying into other projects, its not reuse, but copy & paste programming

Answer 5

For example lets say you have 5 projects you have worked on and between them you have a ton of objects that you think would be useful in other projects.

That's not the code reuse OOP helps with. That's complex and difficult no matter what design process you follow.

The OOP code reuse is about inheritance.