Best Practices - Inheriting from a Class that Lives in a Package

[benjaminhysell]

[cross posted: http://forums.jkisoft.com/index.php?showtopic=1022, not sure what the etiquette is here and if it belongs here or there]

Goal: Create a set of packages that I can distribute to my team that we will use to start off every new project.

Scenarios: I have a set of base classes that we are going to inherit from to generate new code for each new project. As an example, I have a database class. This class has all of the features to allow one to create, read, update, and delete (typical CRUD) and item to move into our out of the database. This base class describes the functionality and provides the API for the rest of the application to call, and based on the object supplied it will perform the proper operation on the database.

This separation also allows for unit testing of the database interactions...I can mock out the database calls during the testing phase of the project if there is a common API for all CRUD for every object going in and out of the database.

Motivation: In my world, the developer has a framework of where to put their CRUD and what VIs they need to overwrite to get their item into our out of the database. Now we have a framework where any developer on the project comes in, opens up someone else's code and goes 'where is the update call for foo1', they goto the class for 'foo1' and lookup the update.vi that has been overriden from the parent class.

Each item that goes into our out of the database has their own CRUD VIs, since each item is different and needs to be inserted and queried from the database in different ways.

Question: What is the best practice to inherit in a project a class that lives in a package? I have found through playing around I cannot inherit from a class in a package, that I actually need to create a VI (I've been calling it 'includes.vi') lay down a reference to the class in the package, and then I can inherit from it in the project. Is there a better way?

Is this a common use of the Package methodology? Would I be better off sending out Project Libraries to my developers?

[Daklu]

QUOTE (benjaminhysell @ Feb 26 2009, 01:57 PM)

Is this a common use of the Package methodology? Would I be better off sending out Project Libraries to my developers?

I recently converted to packages exclusively to distribute reuse code--mostly to myself, but occasionally to others as well. Managing versions and keeping all computers updated with the latest releases is much easier with VIPM than with copy-and-paste.

On the JKI forum Jim mentioned including the parent class as part of the project. Personally I prefer to remove it from the project once I set up the inheritance. The parent class is still available in the Dependencies section of Project Explorer, but the separation makes it clear to me that I should not be editing the parent class' source code. As near as I can tell there's no practical difference between the two methods; it's just a matter of personal preference.