Christian,

Not to be a nay-sayer, but I thought I'd weigh in with a dissenting opinion.

The other posts are correct in saying that you have to compare pro's and con's of each approach. I have done both. There' no clear-cut answer on this one.

*IF* you have a mission-critical application that *requires* regression testing before each update goes into production, AND IF your shared "base" classes change, there will be extra costs (in time, if not cash) each time you update that app. This may not be your situation, but I have a client who insists on this. Each build is numbered and documented, and client bug reports reference the build number. It's imperative in this environment that the "base" classes not be a moving target.

It *IS* more hassle to maintain multiple *copies* of your "base" classes, so there's extra overhead just in project maintenance. The cheapest way, in terms of cost, is to go the "shared" code approach. No debate on this one.

If you use "shared" code, and if there are multiple developers, I think it works best for an individual to be responsible for the "shared" classes. Not that he must do all the coding, but is responsible for code reviews to ensure that compatibility with earlier projects is maintained, and if questions arise, to schedule a build and test cycle on the affected projects.

FWIW, I maintain a "shared" set of framework classes. I subclass them for each project I undertake. Most applications simply reference the "shared" code. However, the "mission critical" application I mentioned earlier gets a *COPY* of the "base" classes, stored under its local directory, and updated only when a new build is about to be issued, along with regression testing.

Source code management is not a simple issue, and I recommend discussing it in developer / project manager meetings, because it directly affects testing and delivery schedules for all projects.


>Hello,
>I have a set of classes, which I reuse in all of my application, let's call it a framework.
>I have following question:
>When I create a new project, shall I just add these classes to the project, leaving them on their original location, or shall I copy them to the directory of the new project?
>I ask this, because I am not sure which is the better way, and maybe someone has experienced some problems with one way or the other.
>For example, adding the classes from their original location would mean, that whenever I want to make some improvements, they are automatically inherited by my new application. Downside: Another application might be disturbed.
>When i copy the classes, and I make improvements which I want to have happen also in another project, I have to make them at least twice (or even more), thus creating a pool of overwork.
>How is this handled with a framework? always copy the classes, or only subclass them and never change the original classes??
>
>Thanks for your time, any suggestions highly appreciated!