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

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

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

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

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

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

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

Так, хорошо, решили разделить их, но как мне быть если мне нужно шарить из 10 различных мест? Каждый раз в каждом контроллере создавать 2 объекта и реализовывать один и тот-же код связи между TextSharer и ServiceConnector? Тогда если мыслить в выбранном направлении следует написать 3ий класс (паттерн Фасад) который будет связывать логику этих 2ух объектов и давать мне легкий и простой шаринг. Или как?