Extended Types and Global Lists

I'm extending a base class and I want each class to have it's own list of objects. But obviously there's not much point having a base class if I have to do everything in relation to the list separately for each type.

Quick example code

Type A
	
	Global List:TList
	
	Method New()
		
		If List=Null
			List=New TList
		End If
		ListAddLast List,Self
		
	End Method
	
	
End Type



Type B Extends A
	
End Type


Type C Extends A
	
End Type



Global AB=New B
Global BB=New B
Global CB=New B

Global AC=New C
Global BC=New C
Global CC=New C

Now if I try to examine the list from any of the types, it's all the same list, with 6 objects, 3 of each. What I'd like is for C to have a list of three C's and B to have a list of 3 B's. But I still want to be able to operate with the list in the base class. Hope that makes sense.

I'll be having an awful lot of extended types and it will be a huge amount of extra code if I can't extend a base type. They all have so much in common that it really ought to be a huge saving, if I could just get lists behaving as I want.

Suggestions?

You could create separate lists in each type, and add them in the New method, but that would put all of your Cs in the B list as well.

Best thing is probably to create 'Create' functions that populate the various lists correctly. You will need to create a list for each class though.

If I can't "extend" the list and the create function, then there's really no code left to share. Practically all the shared code relies on the lists in some manner.

Essentially I am created a large number of "databases". It seemed to me that the most effective way to do this was to have a base class called database which has methods/functions for loading, saving, searching, etc and then extend it down to the individual types. Then all I have to have in each type is the code specific to loading/saving one record. The overall loading/saving can be done in the base class.

Isn't this the point of OO coding, and inheritance in particular? To save having identical code in lots of different places. Granted I'm very new to OO programming and I may be overlooking something very basic, but it's going to be very, very inefficient to have all of the code in every single database type. :/

Create an array of lists. Then have a field in each type to store the index that the list of that type is in the array. Either that or create a new type of container object, because a list is simply too simple to do what you want.

OO has nothing to do with it. Even in C you'd have the same problem.

You could have Load/Save methods in the derived types that override those in the base class.

The base class list handling is properly shared but when it comes to loading or saving an instance the override methods are called.

It sounds to me like you should rethink the overall design. I don't see any reason for the individual types to extend Database. Perhaps they should be types derived from a base Row type ?

Here is a rough outline of how a database structure could be implemented:

- There is a type T_Database that holds everything together and provides initialisation, finalisation and perhaps if required CreateTable, DropTable, statistics etc. It also provides things like the file or directory path and a collection (say a list or array) of T_Table objects

- T_Table contains a collection of T_Column types that define the fields and a collection of T_Row types that store the data in this format. T_Column is only really required if you want to allow for the database to understand the row structure. This is important if you want to implement things like Select with a Where clause or indexes on certain columns.

- T_Row is the base for the types that will actually be stored and manipulated. From it are derived say T_Enemy and T_Planet which are the types you want to handle. The derived types know which T_Table they are related to and they implement override methods to construct themself from (Load) or store themself to (Save) a string, stream, bank or whatever is your physical storage mechanism.

- T_Row contains a lot of the code in methods like Insert, Update, Delete, Select. These are generic and rely on the derived Load/Save methods to operate on the specific type instances. Often the function/method parameters and return values will be variables or arrays of type T_Row. In your calling program of course they will be of the derived types T_Enemy etc which are compatible since they are derived from T_Row.

This can get as sophisticated as you want. Even if you are starting with the simple stuff, think about what the objects actually are and what actions they perform.

- A database is a collection of tables. Databases can be created and dropped.
- A table is a collection of columns that define the fields and a collection of rows that contain the data in that format. Tables can be created and dropped.
- A row contains the fields that make up a single entity. Rows can be inserted, updated, deleted or selected

Perhaps somebody has already made either a BlitzMax interface to a proper DBMS or a DBMS like structure that would meet your requirements ?

I can see how an array of lists helps, but if the list index has to be a field instead of a global, that makes it impossible to create, load, import or anything else where a type instance does not already exist.




I'll take your word for that, but I find it hard to believe. This seems to me like a fundamental requirement if inheritance is to be of any use. This is only my second BMax project and I've really needed it in both. I managed to get by in the last project because I was dealing with small numbers of objects, but dealing with tens or hundreds of thousands of database records, I seriously don't want to slow things down to a crawl trawling through the wrong type of object.

PGF: That's ten times more complicated than I will ever need. I could justify my design but you'll just have to take my word for it that the design the way I have it is perfect apart from the list issue and not be able to "extend" it.

This isn't the greatest solution to the problem but it works. Cajun17 is right this isn't an oop issue. You are trying to do is override the behavior of the Global TList in the base type which isn't how oop works. You would need a new container type. Another possiblity would be to have a function in each dervied type call GetList which would create and return a new TList with only those objects in the global list that are of the specified type. This could get slow though and would create a lot of garbage.

Type Base
	Global AllList:TList=Null
	Global ASubList:TList=Null
	Global BSubList:TList=Null
	Global CSubList:TList=Null
	
	Method New()
		If AllList=Null Then AllList=New TList
		If ASubList=Null Then ASubList=New TList
		If BSubList=Null Then BSubList=New TList
		If CSubList=Null Then CSubList=New TList
		ListAddLast AllList,Self
	End Method
	
	Method AddToSub(list:TList,o:Base)
		ListAddLast(list,o)
	End Method
	
	Method PrintList()
		If C(CSubList.first()) Then
			Print "C " + CSubList.count()
		ElseIf B(BSubList.first()) Then
			Print "B " + BSubList.count()
		ElseIf A(ASubList.first()) Then
			Print "A " + ASubList.count()
		EndIf
		Print "Base " + AllList.count()
	End Method
End Type

Type A Extends Base
	Function Create:A()
		Local o:A = New A
		o.AddToSub(ASubList,o)
		Return o
	End Function
End Type

Type B Extends A
	Function Create:B()
		Local o:B = New B
		o.AddToSub(BSubList,o)
		Return o
	End Function
	
End Type

Type C Extends A
	Function Create:C()
		Local o:C = New C
		o.AddToSub(CSubList,o)
		Return o
	End Function
	
End Type


Global aA:Base=A.Create()
Global aB:Base=A.Create()
Global aC:Base=A.Create()

Global aD:Base=B.Create()
Global aE:Base=B.Create()
Global aF:Base=B.Create()

Global aG:Base=C.Create()
Global aH:Base=C.Create()
Global aI:Base=C.Create()

aA.PrintList()
aD.PrintList()
aG.PrintList()

I didn't say that OOP works the way I'm trying to use it. Obviously it doesn't or I wouldn't be asking the correct way to do it. I said it seems insane if there isn't a different way of doing what I'm trying to do.

The problem with your "solution" is you're still doing all the creating in the derived type, when the whole basis of my question is how to do it in the base type. There's no point in me having a base class if all the shared code has to go in the derived classes. I will just end up with a completely empty base class, because there's nothing left to share.

Well I guess you just answered you own question then. If there is nothing different between the base and derived types other than the list handling you don't need derived types.

I dont think it is a OOP issue.
In my case I have a Sprite type with a global list of all sprites created. The New() method adds itself to the list. This means any new types I create that derive from the Sprite will also automatically add themselves to the List. That is what it is supposed to do. All the derived types are still basically a sprite and therefore do everything a sprite type does.
What your asking for is that each derived type share all the common code but use a unique global field.

I dont think any OO language will do what you want.
In C++ I think you could achieve what you want using Templates. My C++ is not very hot but from what I understand you would write your common code as a template. Then each of the classes you want can be created from the template. The compiler would insert the common code for you. In effect each of the classes would be copies of the template. Equivalent to you cut/pasting your base code into each of your required types.
The alternative is to redesign your code to work differently.

for example : How about if you make the TList local in your base type.

The top level database type will use the TList to store a list of tables.
Each table type stores a List of Columns. So whenever you create a Table the table will have it's own list in which to store the columns.

Just a thought.

No, I said there's nothing that doesn't INVOLVE list handling. List handling, unsurprisingly is a major part of a "database" and there's a ton of code which involves the list in some shape or form. Having to have twenty copies of each function or method, one for each derived type seems insane. I might as well not bother with an OO language at all. I could go back to B3d.

I've probably got completely the wrong end of the stick.

This code will list the Base Class and the extended classes.

Type A
	
	Global List:TList
	
	Field Test:Byte
	
	Method New()
		
		If List=Null
			List=New TList
		End If
		ListAddLast List,Self
		self.test = Rand(0,255)
		
	End Method
	
	
End Type


Type B Extends A
	
End Type


Type C Extends A
	
End Type


Global AB=New B
Global BB=New B
Global CB=New B

Global AC=New C
Global BC=New C
Global CC=New C

' List all types

For allTypes:A = EachIn a.List
	Print allTypes.Test
Next

Print "--------"
' List all B types

For bTypes:B = EachIn a.List
	Print bTypes.Test
Next

Print "--------"
' List all C types

For cTypes:C = EachIn a.List
	Print cTypes.Test
Next

well what are the derived types? I mean what purpose do they serve? What is the base type representing? I think we need more information about what you are trying to accomplish, not just the list issue. Sounds to me like you may not be modeling the problem correctly, hard to tell without know the entire scope of the problem you are trying to solve.

... Edit:

I just reread one of your previous posts. You are modeling the problem incorrectly. Do something like QuiteBloke suggested. Have a Database class that keeps a list of Tables. Each table keeps a list of fields. Each field has a data type and its value.

You don't need a new type for each database.

IndiePath, I came up with the same thing but, if you put timing code in and create a lot of instances, the time taken is the same for each 'eachin' (i.e. it checks every
instance on the list despite it's type).

Type A
	
	Global List:TList
	
	Method New()
		
		If List=Null
			List=New TList
		End If
		ListAddLast List,Self
		
	End Method
	
	
End Type



Type B Extends A
End Type
Type C Extends A
End Type


For my_count = 1 To 50000
  AB=New B
Next
For my_count = 1 To 10
  AC=New c
Next

a_start=MilliSecs()
 For t:a = EachIn a.list
     a_count:+1
 Next
 Print a_count
a_end=MilliSecs()
 Print a_end-a_start
b_start=MilliSecs()
 For u:b = EachIn a.list
     b_count:+1
 Next
 Print b_count
b_end=MilliSecs()
 Print b_end-b_start
c_start=MilliSecs()
 For v:c = EachIn a.list
     c_count:+1
 Next
 Print c_count
c_end=MilliSecs()
Print c_end - c_start

Not to bad with 10nnn but 100nnn wastes a lot of cycles for type 'C'

The "correct" way to do this, is to apply the Composite Design Pattern.

You can't really do it like that.Whenever you're stuck with a creation problem, there's bound to be a Factory pattern that solves it.

Additionally, there is no point in having a base class if the only thing it has in common with it's children is it's attributes.

I know most people here consider OOP (never mind Design Patterns) a complete waste of time. Never the less it does save time, because the problem you have in your program is not unique, someone else will have run accross it before, and figured out a solution.

Tim: Yes, that works and it's how I did it in my previous project, but it's still going through every instance, including all the unnecessary ones. It's not a problem with a few dozen instances, but it is with a few hundred thousand.

EDIT: Oops, TonyG already beat me to that observation.




I covered this once already. I know it's not supposed to do that. I illustrated it like that because that's what I'd like it to do, and I'd like to know the easiest way of doing that.



Only if you're trying to answer a different question than the one I asked. I don't want to do the whole thing in a completely different way, or I would have done. If the answer to "how do I do this?" is "I don't know" or "You can't" that's perfectly fine. I'll find my own way.



Sounds like it would work, but as I said to the previous person to suggest it, it's far more complex than I really need and with some of the other things I'm doing, it's not going to be any faster than just having one list of everthing.



No, modelling the program in a way I don't like is the wrong way to do it. This is a long term, large project and I finish projects because I write them in a way I'm comfortable with.




Yes I do. You just don't know why I do, because I haven't ( and won't ) go into every tiny detail of a huge project. You don't need to know it unless you're trying to tell me do to everything in a completely different manner, which I'm not going to do anyway. I can kludge my own workaround if there's no ideal way to do it.






I have no idea what either of those are, but it sounds like a good jumping off point to go researching and reading. Thanks.



Very good point.

Yeah. Sorry I couldn't provide you with working code, but I haven't had much time for BlitzMAX recently due to other obligations. Besides which I'm sure other people are better at explaining them than me.

The notorious GoF Book is a good place to start, if you're so inclined. It's a classic. :o>

Forgive me, this may sound a bit rude, but...

If you won't explain enough for us to help you and you refuse to listen to the help you are being giving then why did you bother asking the question? It's a bit crappy to ask for help and then yell at eveyone that trys to help you and say they are wrong.

Not at all, a point in the right direction is all I need.



The description makes it sound like a fascinating read. I've never looked into design patterns before, but it sounds like it could be something of a revelation if I can get into it.



You have enough information to help me. You only want more information because you're intent on having me do the project your way. I only do projects someone else's way if they're paying me. If I've misunderstood, I'll let you have my PayPal details and once the payment clears I'll do it just to your requirements. Failing that, I'll do it my way, thanks.


I haven't refused to listen to help. Several suggestions simply don't answer the question I asked. The only help I've seen offered so far which attempted to answer the actual question as it was asked is Tim and TonyG ( and TonyG himself explained why that is just masking the problem ) and FlameDuck, whose advice I think sounds great.

If there's an unwritten rule around here which says I have to take any and all advice offered, regardless of whether it helps or hinders me, I'm not aware of it. I've read all the replies, considered all the replies and picked the one which I think is most helpful. I appreciate the time everyone took to respond, and I believe I was quite courteous to everyone the first time. When it comes to coming back a second and third time to tell me you're right and I'm wrong, you've strayed from helpfulness into arrogance and I'm inclined to be a bit tetchy. I didn't, however, return the favour and say you were wrong, I simply indicated that it wasn't the right answer for me, so that I didn't waste more of your time preaching to me when I had made my decision.



It happened in the early hours in a brief moment of weakness when I forgot how the answer to so many questions on programming forums is like the old Irish joke. Q: "Can you tell me how to get to Kerry?" A: "Well sir, I wouldn't start from here if I was you."



I haven't yelled at anyone. Aside from being impossible to do in type, I didn't even raise my caps lock at you. And it was you arrogantly suggesting my design was wrong, not the other way around. I have every confidence that your design suggestion is perfectly good, I just happen to know the way I work best. It's programming in a manner I'm comfortable with which has enabled me to finish as many projects as I have.



You're right, it did. But since you asked nicely, I'll forgive you.

Another shot in the dark.
Could you have a next_same_type and prev_same_type field which holds the object pointer of the next and previous instance of the same type in the list?
Rather than loop with eachin, run through the next_same_pointer values.
Basically, you'd be simulating the list functions but only for instances of the same type.
You could store these values in global variables within the type.

Hmm.. I'm sure the OOP purists will decry it as evil or at the very least inelegant, but that's a pretty good solution, Tony. If I did things that way, the only speed hit would be storing all the extra pointers when I create and load, which happens very, very rarely. Going through the virtual lists should be practically as fast as going through separate lists. Yup, I like that.

I think I'm still gonna buy FlameDuck's book suggestion, for future reference and self-improvement, but I think that solves my problem pretty well. Thanks :)

I'd do it like this:

Type A
	
	Global List:TList
	
	Field Test:Byte
	Field letter:String
	
	Method New()
		
		If List=Null Then List = New TList
		List.AddLast Self
		
		self.test = Rand(0,255)
		self.letter = "A"
		
	End Method
	
	
End Type


Type B Extends A

	Global List:TList
		
	Method New()
		If List=Null Then List = New TList
		List.AddLast Self
		self.letter = "B"
	EndMethod
	
End Type


Type C Extends A

	Global List:TList
	
	Method New()
		If List=Null Then List = New TList
		List.AddLast Self
		self.letter = "C"
	EndMethod
	
End Type


Global AB=New B
Global BB=New B
Global CB=New B

Global AC=New C
Global BC=New C
Global CC=New C

' List all types
Print "A,B, and C"
For allTypes:A = EachIn a.List
	Print allTypes.letter+","+allTypes.Test
Next
Print "~n"

' List all B types
Print "Only Bs"
For bTypes:B = EachIn b.List
	Print bTypes.letter+","+bTypes.Test
Next
Print "~n"

' List all C types
Print "Only Cs"
For cTypes:B = EachIn c.List
	Print cTypes.letter+","+cTypes.Test
Next
Print "~n"

Fredborg, that's very good.
How does it know which type each list object is without checking them?

Type parent
	Global ncreated=0
	Field num
															
	Method New()
		DebugLog "parent new"
		Self.num=ncreated
		ncreated:+1
	End Method
	
	Method addtolist(list:TList Var)
		If list=Null
			DebugLog "new list"
			list:TList=New TList
		End If
		ListAddLast list,Self
	End Method
	
	
End Type

Type a Extends parent
	Global list:TList
		
	Method New()
		DebugLog "a new"
		addtolist(list)
	End Method
	
End Type


Type b Extends parent
	Global list:TList	
	Method New()
		DebugLog "b new"
		addtolist(list)
	End Method
	
End Type

Global a1:a=New a
Global a2:a=New a
Global a3:a=New a

Global b1:b=New b
Global b2:b=New b
Global b3:b=New b

DebugLog "a list"
For ap:a=EachIn a.list
	DebugLog ap.num
Next

DebugLog "b list"
For bp:b=EachIn b.list
	DebugLog bp.num
Next

Wouldn't have bothered if I had seen FredBorg's first, but here it is, with a slightly different twist. You can see each child type has its own global list (within that type).

Really what you need in this situation is an Adjacency List:

Const TYPE_COUNT = 6
Const TYPE_A = 0
Const TYPE_B = 1
Const TYPE_C = 2
Const TYPE_D = 3
Const TYPE_E = 4
Const TYPE_F = 5


Type AdjList
	Field loopStart:Int
	Field theLists:AdjNode[]
	
	Method New()
		theLists = New AdjNode[TYPE_COUNT]
		For Local i:Int = 0 To TYPE_COUNT-1
			theLists[i] = New AdjNode
		Next
	EndMethod
	
	Method addRelationShip(p:Int, c:Int)
		theLists[p].addChild(c)
	EndMethod
		
	Method addObject(o:AdjType)
		theLists[o._type].addObject(o)
		If o.p_Type = -1 Then Return
	EndMethod
	
	Method removeObject(o:AdjType)
		theLists[o._type].removeObject(o)
	EndMethod
	
	Method onlyThisType:Object[]()
		Return theLists[loopStart].aList
	EndMethod
	
	Method setLoopStart(i:Int)
		loopStart = i
	End Method
	
	Method ObjectEnumerator:AdjIterator()
		Local temp:AdjIterator = New AdjIterator
		temp.theLists = theLists
		temp.n_Index = loopStart
		temp.Init()
		Return temp
	EndMethod
				
EndType

Type AdjNode
	Field children:Int[]
	Field aList:AdjType[]
	Field num:Int
	
	
	Method addObject(o:AdjType)
		If num=aList.length Then grow()
		aList[num]=o
		o.o_Index = num
		num:+1
	End Method
	
	Method removeObject(o:AdjType)
		If o.o_Index > aList.length-1 Then Return
		num:-1
		aList[num].o_Index = o.o_Index
		aList[o.o_Index] = aList[num]
		o.o_Index = -1
	EndMethod
	
	Method addChild(i:Int)
		children = children[..children.length+1]
		children[children.length-1] = i
	EndMethod
	
	Method grow()
		aList = aList[..aList.length+10]
	EndMethod
			
EndType

Type AdjIterator
	Field n_Index:Int
	Field o_Index:Int
	Field theLists:AdjNode[]
	Field que:intQue
	
	Method New()
		que = New intQue
	EndMethod
	
	Method Init()
		For Local i:Int = 0 To theLists[n_Index].children.length-1
			que.push(theLists[n_Index].children[i])
		Next
	EndMethod
	
	Method HasNext:Int()
		If o_Index < theLists[n_Index].aList.length Then Return True
		Repeat
			If Not que.isEmpty() Then
				n_Index = que.pop()
				o_Index = 0
				For Local i:Int = 0 To theLists[n_Index].children.length-1
					que.push(theLists[n_Index].children[i])
				Next
				If theLists[n_Index].aList.length > o_Index Then Return True
			Else
				Return False
			End If
		Forever
	EndMethod
	
	Method NextObject:Object()
		o_Index:+1
		Return theLists[n_Index].aList[o_Index-1]
	EndMethod
	
EndType


	
Type AdjType
	Field _Type:Int
	Field p_Type:Int
	Field o_Index:Int
	
	Method Init() Abstract
	Function ForList:Object() Abstract
End Type



Type intQue
	Field que:Int[]
	Field front:Int
	Field back:Int
	Field num:Int
	
	Method New()
		que = que[..5]
	EndMethod
	
	Method push(i:Int)
		If isFull() Then Return
		que[back]=i
		back:+1
		back:*(back < que.length)
	EndMethod
	
	Method pop:Int()
		If isEmpty() Then Return
		If front = que.length-1 Then
			front = 0
			Return que[que.length-1]
		Else
			front:+1
			Return que[front-1]
		End If
	End Method
	
	Method isEmpty:Int()
		If (front = back) And (num = 0) Then
			shrink()
			Return True
		End If
		Return False
	EndMethod
	
	Method isFull:Int()
		If (front = back) And (num <> 0) Then grow()
		Return False
	EndMethod
	
	Method grow()
		que = que[..que.length+5]
	EndMethod
	
	Method shrink()
		que = que[..5]
	EndMethod
EndType


			
Type A Extends AdjType
	Global List:AdjList
	
	Method Init()
		_Type=TYPE_A
		p_Type=-1
		List.addObject(Self)
	EndMethod
	
	Function ForList:AdjList()
		List.setLoopStart(TYPE_A)
		Return List
	EndFunction
	
	Method setupRelation()
		If p_Type > -1 Then List.addRelationship(p_Type,_Type)
	EndMethod
	
EndType



Type B Extends A

	Method Init()
		_Type=TYPE_B
		p_Type=TYPE_A
		List.addObject(Self)
	EndMethod
	
	Function ForList:AdjList()
		List.setLoopStart(TYPE_B)
		Return List
	EndFunction
EndType

Type C Extends A
	
	Method Init()
		_Type=TYPE_C
		p_Type=TYPE_A
		List.addObject(Self)
	EndMethod
	
	Function ForList:AdjList()
		List.setLoopStart(TYPE_C)
		Return List
	EndFunction
End Type

Type D Extends C
	Method Init()
		_Type=TYPE_D
		p_Type=TYPE_C
		List.addObject(Self)
	EndMethod
	
	Function ForList:AdjList()
		List.setLoopStart(TYPE_D)
		Return List
	EndFunction
End Type

Type E Extends C
	Method Init()
		_Type=TYPE_E
		p_Type=TYPE_C
		List.addObject(Self)
	EndMethod
	
	Function ForList:AdjList()
		List.setLoopStart(TYPE_E)
		Return List
	EndFunction
End Type


Type F Extends E
	Method Init()
		_Type=TYPE_F
		p_Type=TYPE_E
		List.addObject(Self)
	EndMethod
	
	Function ForList:AdjList()
		List.setLoopStart(TYPE_F)
		Return List
	EndFunction
End Type

A.List = New AdjList
	
Local aa:A = New A 
Local bb:B = New B
Local cc:C = New C
Local dd:D = New D
Local ee:E = New E
Local ff:F = New F

aa.Init()
aa.setupRelation()
bb.Init()
bb.setupRelation()
cc.Init()
cc.setupRelation()
dd.Init()
dd.setupRelation()
ee.Init()
ee.setupRelation()
ff.Init()
ff.setupRelation()

aa = New A
bb = New B
cc = New C
dd = New D
ee = New E
ff = New F

aa.Init()
bb.Init()
cc.Init()
dd.Init()
ee.Init()
ff.Init()


Print "---A---"
For aa = EachIn A.ForList()
	Print aa._Type
Next

Print
Print "---B---"
For bb = EachIn B.ForList()
	Print bb._Type
Next

Print
Print "---C---"
For cc = EachIn C.ForList()
	Print cc._Type
Next

Print
Print "---A---"
For aa = EachIn A.ForList().onlyThisType()
	Print aa._Type
Next
Print
Print "---D---"
For dd = EachIn D.ForList()
	Print dd._Type
Next

Print
Print "---E---"
For ee = EachIn E.ForList()
	Print ee._Type
Next

Print
Print "---F---"
For ff = EachIn F.ForList()
	Print ff._Type
Next

Since there've already been solutions posted I won't document or explain it unless someone would like me to. Basicly it's a list of lists with a hierarchy. The base can see the objects that extend it. Also 20 extended types can be extended by 5 types etc... and will all be in one list.

Thanks for the additional suggestions. I've decided to go with my own solution for the moment. Since none of the databases need to interrelate in the base class, I have a tiny function in each of the extended classes which copies list handles and anything else in the way of type globals into globals held in the base class. I call that function ActivateDB() and then just

ADB.ActivateDB() and
Database.Load()
Database.Save()

..or whatever

I'm sure it's inelegant and whatever else but it lets me keep things the way I want them and it works great so far.