On Sunday 05 October 2003 17:23, Eric Wilhelm wrote: > > The following was supposedly scribed by > > Fergal Daly > > on Sunday 05 October 2003 06:54 am: > > >That said, having a single package so full of stuff that you need to split > > it into sub files is often an indicator that you're doing way too much in > > one package anyway. It's possible you could benefit from mixin classes. > > That is classes which contain only methods and these methods make very few > >assumptions about about their $self object. > > I do have Get and Set methods which would allow functions like Move() to > operate without directly accessing the data structure, but they would still > have to know about the per-entity data structure (i.e. I could later change > where the entity is stored in the object, but the functions need to know > about some of the details of the entity.) Is this enough separation?
It's not so much a question of "is it enough?", it's more "is it useful?". Mixin classes are useful in a situation when you have several different classes which share a set of methods but do not inherit from a common ancestor. For instance if you have Array and IndexedHash (a hash that can also be used like an Array) then if they have the same interface, you could write a mixin class Sortable and get both of them to inherit from it and voila you get 2 sort methods for the price of 1. I'm not sure if this is relevant to your situation (I suspect not as you seem to only have 1 class of objects that you work with). F
