Filip Gruszczyński wrote:
> class Element(object):
>>operations = "Element operations"
>>
>>
> class Group(object):
>>operations = "Group operations"
>>
>>
> e = Element()
> g = Group()
>
> e.operations
>> 'Element operations'
> g.operations
>> 'Group op
On Jan 8, 1:50 pm, "Filip Gruszczyński" wrote:
>
> But I am looking for a different type of flexibility. I would like to
> be able to add more classes to my hierarchy and not have to change my
> code in many places when I add new class to the hierarchy. If I have
> to change every class in the hie
> Yes. There is a difference between the interface of an object (namely,
> what methods and attributes it has and what their semantic meaning is)
> and the class of an object (what methods and attributes it has and how
> they are implemented.)
>
> In general, you shouldn't be asking about an object
On Jan 8, 1:00 pm, "Filip Gruszczyński" wrote:
>
> Is it really any better than asking for class? I mean, if I need to
> add another class to a hierarchy which behaves differently, will it be
> more flexible (actually you have to add another method to every class
> and check for in the gui). I bel
On Jan 8, 1:00 pm, "Filip Gruszczyński" wrote:
>
> Is it really any better than asking for class? I mean, if I need to
> add another class to a hierarchy which behaves differently, will it be
> more flexible (actually you have to add another method to every class
> and check for in the gui). I bel
>class Element(object):
>@staticmethod
>def is_leaf(): return True
>@staticmethod
>def is_branch(): return False
>
>class Group(object):
>@staticmethod
>def is_leaf(): return False
>@staticmethod
>def is_branch(): return True
>
On Jan 8, 8:16 am, MRAB wrote:
> Filip Gruszczyński wrote:
> > Hi!
>
> > I have certain design problem, which I cannot solve elegantly. Maybe
> > you know some good design patterns for this kind of tasks.
>
> > Task:
>
> > We have a model which has two kinds of objects: groups and elements.
> > Gr
I'd love to have operations methods, which would return names of
operations and references to proper methods. The problem is that
certain operations require more, than just running some operation on
the Group or Element. Let's say, you want to add new group to an
existing one - you can't do that to
Filip Gruszczyński wrote:
class Element(object):
operations = "Element operations"
class Group(object):
operations = "Group operations"
e = Element()
g = Group()
e.operations
'Element operations'
g.operations
'Group operations'
But this is the same as asking for a clas
Filip Gruszczyński wrote:
> Hi!
>
> I have certain design problem, which I cannot solve elegantly. Maybe
> you know some good design patterns for this kind of tasks.
>
> Task:
>
> We have a model which has two kinds of objects: groups and elements.
> Groups can hold other groups (subgroups) and
Filip Gruszczyński wrote:
class Element(object):
operations = "Element operations"
class Group(object):
operations = "Group operations"
e = Element()
g = Group()
e.operations
'Element operations'
g.operations
'Group operations'
But this is the same as asking for a clas
class Element(object):
>operations = "Element operations"
>
>
class Group(object):
>operations = "Group operations"
>
>
e = Element()
g = Group()
e.operations
> 'Element operations'
g.operations
> 'Group operations'
But this is the same as asking
Filip Gruszczyński wrote:
Hi!
I have certain design problem, which I cannot solve elegantly. Maybe
you know some good design patterns for this kind of tasks.
Task:
We have a model which has two kinds of objects: groups and elements.
Groups can hold other groups (subgroups) and elements. It's a
Hi!
I have certain design problem, which I cannot solve elegantly. Maybe
you know some good design patterns for this kind of tasks.
Task:
We have a model which has two kinds of objects: groups and elements.
Groups can hold other groups (subgroups) and elements. It's a simple
directory tree, for
14 matches
Mail list logo
