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 :)



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.

  • 1
    Fixed the question so it refers to classes now. – Ominus Jun 23 '11 at 14:19
  • 4
    +1 for the discoverability comment. At my last count, our code base has 7 nearly identical implementations of zlib decompression. – Karl Bielefeldt Jun 23 '11 at 14:47
  • 2
    @Karl Bielefeldt: Yikes, that's not just Not Invented Here; it's Not Invented Here In The Last Five Minutes (NIHITLFM). – Ant Jun 23 '11 at 14:57
  • 1
    @Ant: Often happens in massive (and usually well-aged) projects where the time to find the earlier implementation is perceived as being longer than just implementing a new one. This may be exacerbated by documentation that is inadequate by either omitting these features or by being so huge and overwhelming that most people just read the first few pages and look at the high-level diagrams because searching the documentation is almost as time-consuming as searching the codebase. – FrustratedWithFormsDesigner Jun 23 '11 at 15:00
  • 1
    Documentation is the key. Even you will forget what you coded 6 months ago. If it is not documented, it might as well not exist. – Jim C Jun 23 '11 at 15:25

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.

  • (+1) Because the situation that all projects have the same version of a library, cannot be applied always in real world, specially if a bug has been found, an a previous version of the library is required ;-) – umlcat Jun 23 '11 at 16:35

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:

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

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


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.

  • I didn't put the (-1), but your answer its wrong, because its the opposite stuff... – umlcat Jun 23 '11 at 16:36

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.