[Tutor] class initialization with a lot of parameters
C.T. Matsumoto
c.t.matsumoto at gmail.com
Wed Nov 11 11:08:25 CET 2009
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 <alan.gauld at btinternet.com>wrote:
> "C.T. Matsumoto" <c.t.matsumoto at gmail.com> 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 - Tutor at python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
>
--
Todd Matsumoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20091111/da0d7689/attachment-0001.htm>
More information about the Tutor
mailing list