Original Post
I'm doing some refactoring of a Winforms app, and a particular piece of code doesn't smell right to me. I have a custom control class (call it Canvas), on which a number of Tools can act on it (typical drawing tools such as paint, line, fill, etc.)
Since the Canvas class has grown rather heavy (both in size and public interface), I thought I'd seperate out each tool into a seperate class, which interacts with Canvas directly. Each Tool object is notified of relevent input messages, and communicates back to the Canvas in order to draw, save state for undo, query any necessary data, etc. To do this, each Tool stores a reference to Canvas, and vice versa.
Since Tool needs to communicate with Canvas (and vice versa), it can only do so through public methods on Canvas. Thus, the public Canvas interface isn't getting any smaller/simpler as I'd hoped, although it now has a manageable footprint at least.
To generalize, if I have a class A which the client (application) interacts with, and a class B which interacts only with A (to handle logic related to A), how do I provide an interface on A for B to use that is not exposed to the client?
The obvious answer is to seperate out A and B into its own assembly, make B an internal class, and add internal methods to A for B to call. I've also thought about hooking into events exposed by B, but I'm not sure this is the ideal use for events.
So I'm wondering if I'm missing something obvious here, a better way, or at least an alternative to seperate assemblies?
Then again, maybe I'm over-thinking things as I sometimes do...
Thanks for any suggestions.
Since the Canvas class has grown rather heavy (both in size and public interface), I thought I'd seperate out each tool into a seperate class, which interacts with Canvas directly. Each Tool object is notified of relevent input messages, and communicates back to the Canvas in order to draw, save state for undo, query any necessary data, etc. To do this, each Tool stores a reference to Canvas, and vice versa.
Since Tool needs to communicate with Canvas (and vice versa), it can only do so through public methods on Canvas. Thus, the public Canvas interface isn't getting any smaller/simpler as I'd hoped, although it now has a manageable footprint at least.
To generalize, if I have a class A which the client (application) interacts with, and a class B which interacts only with A (to handle logic related to A), how do I provide an interface on A for B to use that is not exposed to the client?
The obvious answer is to seperate out A and B into its own assembly, make B an internal class, and add internal methods to A for B to call. I've also thought about hooking into events exposed by B, but I'm not sure this is the ideal use for events.
So I'm wondering if I'm missing something obvious here, a better way, or at least an alternative to seperate assemblies?
Then again, maybe I'm over-thinking things as I sometimes do...
Thanks for any suggestions.
