Two solutions come into my mind:

1. Do not inherit from DatabaseConnection, but pass a DatabaseConnection object as a parameter to the FireBirdConnection's __init__function. After this you can delegate the necessary functionality to the DatabaseConnection (by using __getattr__). This introduces less coupling between DatabaseConnection and FireBirdConnection, event module testing is easier.

I do not like this solution. I would like to use the classic 'generalization/specialization' idiom, where the base class defines the interface and some common methods; while the descendants are specializing the basic classes. The language should allow me this classic approach and indeed it does.



2. Maybe the layering of your application is wrong. If DatabaseConnection provides common functionality to the different Adapters, it should be on the same layer or one beneath the Adapters.

I have a bad feeling about it. For example, I have database related modules under Db. I would like to implement the basic abstract classes at the top level, then implement the specialized classes at deeper levels. E.g. I can access DatabaseConnection, DatabaseSchema, SQLProcessor and similar classes in the top level module "Db". I would like to implement as much functionality in this abstract level as possible (reusing code is important for me). Then at some point when I want to implement something - for example, a connection class for PostgreSQL databases - then I only need to implement the unimplemented or extra features of a PostgreSQL connection. There can be many different implementations, this is why I want to store the more implemented (less abstracted) levels deeper in the source tree. I cannot imagine how could it be in the opposite direction. The abstract classes at the top level need to import their abstract counterparts, so I cannot place the abstract classes in the deepest folders - I need to place them at top level because they use each other very frequently. Do you disagree? Is this a bad design from me?


--
_________________________________________________________________
 Laszlo Nagy                  web: http://designasign.biz
 IT Consultant                mail: [EMAIL PROTECTED]

                Python forever!


-- http://mail.python.org/mailman/listinfo/python-list

Reply via email to