Great, I do see my objects working as functions so my OOP understanding needs development. I've got to roll this around to come up with a design which will be more OOP centered and change the code accordingly. To start I could move CompareTableList into DB. This will make a list of tables that need to retrieved.
The Table object you described I find more complicated if each table stands on its own it is decoupled from its compare partner. I suppose a function that pairs the tables, feeding a Table object to its partner Table.compare method. Hmm ... This has got to sink in. T On Wed, Nov 11, 2009 at 10:28 AM, Alan Gauld <[email protected]>wrote: > "C.T. Matsumoto" <[email protected]> wrote > > First I've got a db class >> >> class DB(object): >> """ This does all the database handling. >> """ >> > > That's fine. > > > Then I've got a class to filter a list of potential tables to be compared. >> These tables need to be tested. >> > > OK, Could that be a method of your database? > > > class CompareTableList(DB): >> """ Make a master list, from a source list of compare tables >> that need to be compared. >> If the tables in the list pass the tests make a CompareItem. >> Store all the CompareItems in a compare_list. >> """ >> > > I still think that from an OOP sense it would be m,ore logical to > have a Table cklass that knows hhow to compare itself to another table. > > You are trying to build an object which is a function, thats rarely > a good idea. You wind up with the worst of procedural and OOP > worlds coming together. > > > CompareItem is the class in question. >> >> CompareItem(object): >> def __init__(self, ref_table, ref_dburi, ref_rows, test_table, >> test_dburi, test_rows, keys): >> ... >> ... >> >> This would be your suggested TestTable only it already has the pair and is >> ready to be compared. Rather than a method compare is a class. >> > > I suspect thats your problem. cComparing things is normally an > operation of a class not a class in its own right. A compare class > would need to inspect the internal details of at least 2 objects. > But objects should manage their own data not expose it to third parties. > So either you have to pass in all the object attributes you want to know > about - long parameter lists or you pass in two objects and violate data > hiding within the comparison. > > > Compare(CompareTableList): >> """ Foreach CompareItem in the CompareTableList.compare_list. Workout >> the differences and store difference in something that can format >> a report. >> """ >> > > Again this looks like a method of your database. > > db.compare(tables) > foreach table in tables: > if table.compare(masterTable?): > storeDifferences() > > or > > db.compare(table_sets): > for table1, table2 in table_sets: > if table1.compare(table2) > storeDifferences() > > Or similar. > > By trying to create objects which are functions instead of making > the function a method of the objects that they act on you are > complicating your code. > > > -- > Alan Gauld > Author of the Learn to Program web site > http://www.alan-g.me.uk/ > > _______________________________________________ > Tutor maillist - [email protected] > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor > -- Todd Matsumoto
_______________________________________________ Tutor maillist - [email protected] To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
