Splitting a large class and problems with a field needed in multiple classes as a result
So one of my classes got too big, so I decided to split it off into multiple classes. But there is a field containing an object that I will need in multiple classes now.
My study exercises usually focused a lot on not having bidirectional associations, so I assumed that was the preferred way to go about it. But I couldn't work out on how to do this in a way that doesn't feel like a hack or mess at the very least. Right now it still looks somewhat like this:
3 Replies
So when outside code wants to call GetEmail() for example, they will call the OnlineConnectors implementation of it, which is a single line of code that calls the GetEmail() function in the EmailConnector, passing down the "connection" as a parameter and returning its return value. I can't help but feel this is very shoddy work and I am questioning if bidirectional association might be the answer - that way I could call the method in the EmailConnector directly and it could get the OnlineConnection from the associated OnlineConnector.
But I've practiced avoiding bidirectional associations during my education so much that at this point I can't help but feel that is a hack too! Am I thinking about this wrong / going about this wrong?
what is OnlineConnector, why would you use that to call GetEmail?
i feel like you're missing a class here
either
- OnlineConnector is a class that hold some settings, for example the connection as you say, so it should do just that (so to call GetEmail you have another class or you call connector directly)
or
- OnlineConnector is an interface that groups email and calendar services, and so CalendarConnector and EmailConnector should obtain their settings from another class
It's actually exactly the second case, I'll follow with what you suggested! thank you!