Congratulations, you've just abused the partial keyword :)
In all seriousness, partial is really only useful for extending classes that contain generated code. The generated code stays in one file, you modify another.
Your scenario here shows that the Twitter class is doing way too much. You should break this up into separate classes, each with 1 responsibility.
You might end up with a Twitter class that is a simple gateway into a deeper object model.
Michael Koby
· 2 months ago
Funny that you mention that I should probably move stuff out of the Twitter class, as it's something I've been considering for a while but haven't come up with something that makes sense to me. It'll happen eventually, but whatever I do, I need to make sure I understand it and why there's value in it rather than just doing it because it' simply "better". But again, I agree, the Twitter class is most definitely doing too much and needs a better design.
Peter
· 2 months ago
The 140-character limit is getting to me, so I'll leave a comment here as well.
I think that even if you can't split the methods of your Twitter class up because you have to have one class that represents the API, that's fine. But consider making those methods one-line stubs that call methods in other classes where all the REAL work is done. That if nothing else will shrink the Twitter class--if not by methods, then by lines of code.
Also I don't know if the Twitter library has any state at all, so it may not make much sense to split the big class up into a bunch of smaller ones--some things lend themselves to OO better than others.
All Comments
In all seriousness, partial is really only useful for extending classes that contain generated code. The generated code stays in one file, you modify another.
Your scenario here shows that the Twitter class is doing way too much. You should break this up into separate classes, each with 1 responsibility.
You might end up with a Twitter class that is a simple gateway into a deeper object model.
class, as it's something I've been considering for a while but haven't come
up with something that makes sense to me. It'll happen eventually, but
whatever I do, I need to make sure I understand it and why there's value in
it rather than just doing it because it' simply "better".
But again, I agree, the Twitter class is most definitely doing too much and
needs a better design.
I think that even if you can't split the methods of your Twitter class up because you have to have one class that represents the API, that's fine. But consider making those methods one-line stubs that call methods in other classes where all the REAL work is done. That if nothing else will shrink the Twitter class--if not by methods, then by lines of code.
Also I don't know if the Twitter library has any state at all, so it may not make much sense to split the big class up into a bunch of smaller ones--some things lend themselves to OO better than others.