[Tutor] rationale for nested classes?
Mac Ryan
quasipedia at gmail.com
Mon Aug 17 23:22:12 CEST 2009
On Mon, 2009-08-17 at 20:27 +0100, Alan Gauld wrote:
> > way I could enforce behaviours like "not null" or "default" from within
> > the datastructure itself (for example in the __init__ method) rather
> > than enforcing a logic from outside (i.e. the "mother class").
>
> But those features are features of the record not of the table.
> A table is simply a collection of records. Most of the functionality
> should be in the record, the table should only need to insert,delete,
> search, sort etc. And those methods should be written to use
> polymorphism to be record independent
I suppose one of us is missing the point of the other one, as it looks
to me that we are saying the same. :) I would indeed enforce those
checks and defaults in the child class (i.e. nested) so that the mother
class can have "generic methods" that would work with various records.
Indeed - if I truly wished to use nested classes - I would probably
define certain module-wide "generic" classes for both "tables" and
"records" and then I would subclass them in hierarchic form, so that the
class TableA(Table) has a nested class RecordA(Record).
I would think of that as a legitimate design with strong encapsulation.
Again though... I am not advocating for this method as "the best one", I
am just try to imagine a "rationale for nested classes" as per request
of the OP.
> > I believe classes/objects are also the most elegant way to implement
> > singletons, so maybe if you need a singleton for each object generated
> > with the "mother class", maybe that is also an occasion in which a
> > subclass comes handy.
>
> I have no idea what you mean by that bit. Classes can be used for
> singletons but I don;t see where nested classes come into it.
Mmmm... giving a second thought to it, what I had in mind can be
achieved with a single class. So apologies, disregard this bit! :)
> > would be very happy if any of the tutors would comment on what above,
> > even if it is for disagree with it! :)
>
> Be very happy! :-)
> More seriously, I suspect from your comments that you too are
> getting confused about the difference between inheritance and nesting.
> nesting is about hiding the class name and definition. Inheritance is
> about subclassing. They are very different concepts. Nesting tends
> to make subclassing more difficult (albeit in Python only trivially so)
Well, thank you for the feedback indeed. I am one of those people who
get their mind clear only when they interact with others. As for the
confusion between nesting and inheritance... no, I think I have that one
pretty well under my belt. :)
Thank you again,
Mac.
More information about the Tutor
mailing list