So there are two possibilities here. One is that you have an object that can rotate, but shows no change in the process. The other is that you have an object that is defined by it's direction. Each ought to be handled separately and in their own way.
So for circle, we have a stub for a rotate function since there is no change in the system. Don't like it, too bad. I'm putting off my quiz on point groups to write this.
For upward arrow, we throw an exception since we don't want to drive the wrong way on a one-way street and this ought to be constant anyway.
In my case, I'm defining a point in 3 dimensional space by inheriting operations from a class defining a quaternion. The 3 dimensional point only uses the 3 imaginary coordinates of the quaternion and if the quaternion has a non-zero value for the real component, it will ruin the vital operations of the rendering algorithm inherited from the quaternion via the 3 dimensional coordinate.
Excuse me for being overly philosophical, however, this question raises a valid point in CS about how this should be handled. As Stephen notes, being able to hide, disable or remove the inherited function in the child class "...would violate the substitutability principle and would break polymorphism."
My case falls under the upward arrow, except I'm pointing into imagination. I am attempting to truncate a derived class, which means any 'grandchild' class (possibly inheriting spin operators) would no longer necessarily be quaternions. It would be more elegant to avoid resorting to throwing exceptions, by trimming the base class at the typecast for a truncating derived class. The alternative would be defining the 3 dimensional coordinate as a separate class with a quaternion member variable; the drawback is that the implementation has too much glue.
Then I can put the new spin operations into the derived class for the 3 dimensional coordinates for the three planes (ij, jk, ik) and then the objects with 3d vertices can be rotated via a loop and an identical member function call for each vertex. You might could keep track of the symmetry on your own, before you start rotating the points defining the surface of sphere, which is why you need to use the stub function and possibly implement your own 'constant' flag.