What I like with having class is that you can attach behavior
aTop opposite
-> aBottom
Le 23/7/15 02:40, Peter Uhnak a écrit :
Hi,
I am trying to figure out where to best place some mapping/data/stable
methods.
For example imagine method
~~~~~~~~~~~~~~~~~~~~~
MyRectangle>>oppositeSides
^ { #top -> #bottom.
#bottom -> #top.
#topLeft -> #bottomRight
....
} asDictionary
~~~~~~~~~~~~~~~~~~~~
And then the class might have some other related methods such as
~~~~~~~~~~~
MyRectangle>>oppositeSideFor: aSide
^ self oppositeSides at: aSide
~~~~~~~~~~~~
So it's a method returning a mapping between opposite sides/corners
and thus is really not going to change.
Now I could place this in instance-side and create a new instance
every time I wanted to use it (which doesn't seem practical), or I
could put it in class-side.
The problem I have with class-side is that naming is more like going
through minefield (more than once I corrupted my image by naming a
method or variable something I shouldn't have), and for whatever
reason it feels like either metaprogramming or procedural
programmming... That class side methods are pretty much global
functions/variables... and short of constructors I am avoiding static
methods even in other languages... but maybe using it is ok. Or maybe
have it object an use singleton?
The only oop-like approach I see would be to extend symbols (#top
oppositeSide), or have separate objects for sides, but that seems like
overkill.
MySide subclass: #Top
Top>>oppositeSide
^ Bottom new
Are there any best practices regarding this? This is also true for
actual data stored in methods/attributes (such as icons).
P.s.: For english natives... Should the second method be ned
"oppositeSideOf:" or "oppositeSideFor:"?
Any ideas/pointers appreciated,
Peter
