Development of Class Libraries in Teams
Because class libraries (.vcx files) are a crucial part of most Visual FoxPro applications, teams must be able to coordinate development efforts when creating them. Working with class libraries in a team involves many of the same coordination issues that any set of application components does, but adds some issues unique to classes:
- Changes to classes are propagated not just to applications that use those classes, but to all subclasses derived from them.
- Multiple classes are often stored in a single library file, the minimum unit that can be managed by a source control system.
As with complex forms and programs, it's good practice to isolate development in a class library, so that one developer can make changes to the library without affecting the work of other developers. Ideally, the team of developers can work with a class library while it's being enhanced by another developer, without having to worry about whether changes to the libraries will cause problems in the application.
When a class is used, Visual FoxPro caches it on the user's computer, even after a form that uses the class has been released. You must explicitly release the class before Visual FoxPro will recognize it as no longer in use. If you've used a class during the current session (and it's therefore cached), but want to load a new version of the class, be sure to release the class to force Visual FoxPro to reload it from the changed library.
Putting Class Libraries Under Source Control
When you put a class library under source control, only one developer can check the library out at a time. The library becomes read-only for other developers. As a rule, this doesn't interfere with application development, because developers can use and subclass a library even if it's read-only. While the application developers work with the read-only version of the library, the class library developer can modify all the classes in the library.
If you use this approach, the developer who is updating the library shouldn't check in the file until it has been finished and tested. Otherwise, other developers will get the incomplete version of the file when they update their project file lists or get the latest versions of files.
If the library is very complex, you can also consider breaking it into smaller libraries for development. Another advantage of this approach is that smaller library files load faster. However, this means that different classes might be finished and available at different times.
Because each approach has its advantages, you should examine the requirements of your development team and choose the strategy that best fits how you work.
See Also
Development and Modification of Databases in Teams | Developing in Teams | Management of Files in a Source-Controlled Project |Displaying File and Project Information