[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 (anyone who's read design patterns or some equivalent) could outline some general ideas of class building, giving full credit to the authors of the book of

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 clearly what
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.