Здравствуйте, CatWarrior, Вы писали:

CW>Мои коллеги сказали что так делать неправильно и надо хранить объекты классов TextSharer и ServiceConnector на одном уровне т/е/ в контроллере (MVC) вида на котором мы хотим шарить текст. Контроллер должен в начале подключиться к сети через объект класса ServiceConnector а затем по результату обратиться к TextSharer и отправить текст. Если запрос на отправку текста у объекта класса TextSharer был вызван без предварительной авторизации то метод объекта TextSharer должен вернуть ошибку.

Согласен с вашими коллегами.

CW>Я вот не очень понимаю такой подход, да он гибче, TextSharer ничего не будет знать о ServiceConnector, но тогда если придется использовать TextSharer в других контроллерах, возникнет дублирование кода, т/к/ для выполнения шаринга необходимо быть подключенным к соцсети.

В вашем варианте TextSharer берёт на себя слишком много — и шаринг текста, и подключение, и проверку состояния. Эта логика должна быть размещена отдельно.
Попробуйте написать тесты для вашего TextSharer. Если выяснится, что невозможно ему подсунуть мок соцсети, то ваш подход однозначно не гибче.

Можете посмотреть аналогии в ADO.NET: DbConnection (класс соцсети), DbProviderFactory (у вас нет аналога), DbCommand (TextSharer и прочие операции).
Конечно, ADO.NET решает гораздо более сложные задачи, но идеи можно подсмотреть.