constructor

Started by
9 comments, last by Crispy 21 years, 10 months ago
quote:Original post by Crispy
1) I do want TSoundManager to be derived from TSoundObject because of a bunch of functions that would otherwise have to be rewritten (such as playback functions which make TSoundManager a wee bit more than a simple container for a set of sounds - I could use an array or a vector for that and not create a class at all. TSoundManager is like the song object into which all of the sounds have been mixed - it is basically a simple waveform consisting of sounds and dynamic stuff that I call events that describe the behaviour of these sounds over time).

This still doesn''t sound like public inheritance. It sounds more like composition and delegation. You already have composition because you have a vector of TSoundObjects, you should delegate to them by iterating around the vector.
quote:
2) It is essential that I keep TSoundObject objects in the vector because they contain a bunch of info that is not described by TWaveForm, such as some dsp stuff to create a sound based on the waveform; if the sound has a looping point, where it is, etc.

That makes it sound like a TSoundObject IS-A TWaveForm does not apply, so again you should not be using public inheritance. Consider composition here too.
quote:
3) Massively overcomplicating is probably what I do most of the time when I don''t know the solution at the first glance. That''s what everybody does (I hope ) - so there you have it. I was simply trying to think of the most optimal way to preserve both memory consumption and code size.

Premature optimisation often results in over-complication. Forget about memory and size, and concentrate on getting it right. I''m pretty sure you won''t get a performance problem.

This topic is closed to new replies.

Advertisement