Okay, since I could use the practice I created an example project to show what vikingosegundo and I mean.
Here’s the gist of it:
For this example I kept all relevant code except the adding and removing of shapes in a GHShapeDemoView.
I used structs to define the shapes, but treat them as one “unit” of data that is handled during drawing, adding to the view, etc. All shapes are kept in an array and during drawing that is iterated and all found shapes are drawn using a simple NSBezierPath.
For simplicity’s sake I just chose some random fixed points for each shape, in a real project that would obviously be determined in another way (I was too lazy to add input fields…).
Even here there are a lot of ways to refactor (probably). For example, one could even make each shape a class of its own (or use one class for shapes in general). Maybe even a subclass of NSView, that would then result in the “drawing area” itself not be a custom view, but a normal one and on button presses relevant shape views would be added as subviews. That would then probably also get rid of all this points-calculating stuff (mostly).
In a real project I would probably have gone for shapes as layer subclasses that I then add to the subview. I’m no expert, but I think that might have performance benefits depending on how many shapes there are and whether or not I would animate them.
(Obviously the highest performance would probably be gained from using OpenGL ES or something, but I have no clue about that and that’s far beyond the scope of this question).
I hope this provides you with a good starting point to work on your drawing. As stated above I would strongly suggest restructuring your project in a similar way to properly define a flow of what you draw and how you draw it. If you somehow must rely on keeping points data in enums or structs or something, write adequate mappers to your drawing data structure.