[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