[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] Re: [sc-users] Synth.play revisited
On Wednesday, July 24, 2002, at 02:03 PM, <godpup@xxxxxxxxxxxxx> wrote:
i'd like to re-iterate the importance of that statement. perhaps we
who's read design patterns or some equivalent) could outline some
ideas of class building, giving full credit to the authors of the book
actually i picked up most of it by osmosis thru james' sc code. when i
read the book
i was like 'yeah yeah yeah... i get it'.
but still a must read.
knowing the responsibilities of an object is very important.
often simply building a good representation of the reality of the
situation is enough
to make things work !
like the Synth Group Node classes i did, its just a matter of laying out
the problem is, what the object is meant to represent.
then certain things like automatically making a unique id, depositing
yourself into a parent
node and group etc. these things all happen quite easily.
by burdening the design of this class with more responsibilities and
'systems' and "api that supports
such and such..." , you lose
flexiblity. and when you change your mind, you have to redo the whole
class. or keep a lot of methods
around that support systems that only certain people use.
certainly + ext method files help that a lot to... there are sometimes
when each object should support a message
in order to implement some system.
perhaps this would be helpful (not only with SC code, but also with
the underlying obj-c and c++ code)
to others so that class conflicts such as
these can be avoided.