Jim Dettman
jimdettman at earthlink.net
Mon Mar 15 13:58:16 CST 2004
John, << Our wrapper allows us to do nothing more than add custom functionality to THAT wrapped object. >> So you'll end up with lots of classes, unless I mis-understanding your intent. For example let's start with a base text box class. In a typical app, you can have text boxes that can be used for: 1. Text input 2. Input of a short date 3. Input of a short date and time #2 and #3 are variations of #1 and contain some of the same behaviors and methods. So at the frame work level, I'm going to provide three classes or I'm going to do one class (text box) and overload it with properties to accomplish #2 and #3. But what your not doing is starting with #1, then creating #2 and #3 based on #1. I'm also assuming that it's not your intent to do a lot of instance specific behaviors. For example, if I want to add a popup calendar to all my text boxes that work with a date, I can't do that easily if I stuck with a single text box class and handled date/time issues at the instance level. In that case, I should not have bothered with a framework at all, but instead create tools to manipulate instance specific items. In fact now that I say that, I'm wondering how you would roll out new versions of the Framework. If I as a developer have no choice but to modify your classes (because it's a single layer) and you distribute a new version, how can I easily implement it? The only alternative is to provide a large number of hook procedures that your class calls to find out if the developer wants to change anything. Anyway, excluding the last two options, this means that if you go the three class route, you are coding the "text box" behavior (i.e. background color when active) in three places, thus eliminating some of the benefits of doing it in the first place. If you do one class, you end up with a lot of code, some of which you might not always be need. It also increases the complexity of the text box class. Even with the limited OO capabilities of Access, there are still design issues in how to approach a framework that will have an impact on performance. The other issue you mentioned (object cleanup) also bears directly on performance, which is what initially prompted my comment. Jim (315) 699-3443 jimdettman at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John W. Colby Sent: Saturday, March 13, 2004 8:43 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Framework Discussion - Dependent Objects Jim, What I think that you are forgetting is that VFP. like .NET is a system with true inheritance. Access is not. Thus with VFP or .Net you can get bogged down with classes inheriting classes inheriting classes inheriting classes inheriting.. And of course all that inheritance has to be "built up" as the classes load. Access has none of that. Nothing inherits anything. What a framework in Access really provides is nothing more than objects (classes) written for a specific purpose, to perform specific processing. Often they are wrappers around objects that have no classes of their own allowing us to "simulate" in a very crude sense inheriting the object, but the "inheritance chain" comes to a screeching halt immediately unless of course you were to write a wrapper to a wrapper to a wrapper. Our wrapper allows us to do nothing more than add custom functionality to THAT wrapped object. Of course a class can instantiate another class to obtain encapsulated services that it needs but that is hardly the same thing as what you are referring to. In the end, my current framework has... 45 classes (I just went and counted them). Of that number, 17 are wrappers to the various controls and the form. The rest are "services" of one type or another - FTP, HTTP, Zip, Unzip, Enigma, MD5, Sysvars, Timer, AuditTrail, DependentObjects etc. Access is NOT a true OO environment. It has objects, of which you manipulate methods and properties, however true inheritance is virtually nonexistent. The issues that you refer to with VFP and .NET simply cannot occur in Access because of that. Believe me, given my druthers I'd take true inheritance and deal with the speed issue that might occur. John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Jim Dettman Sent: Saturday, March 13, 2004 5:38 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Framework Discussion - Dependent Objects John, <<I have a usable framework already, in fact I am looking at my old to find subjects for these articles.>> "Useable" was probably a poor choice of words on my part. I was really thinking in terms of features. I slid into "useable" in the sense that by the time you add everything that everyone might want, you've got everything except the kitchen sink<g>. << Would you notice an additional 1/50th of a second for the framework to do it's thing?>> I only mention it because as you get further down the road and into composite classes, there gets to be a design decision in regards to how a framework should be structured for what offers. The out come of that can have a large impact on performance. This is one of the hot button issues with VFP frameworks, which you know are quite a bit farther down the framework road. Considering that VFP is a true compile and it's an issue there, I don't see how it could not be an issue at some point with VBA. Jim (315) 699-3443 jimdettman at earthlink.net -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com