Когда Вы прекращаете инкапсулировать?
Короче говоря: невозможно поддерживать поля r_basicprofile без подачи заявки на партнерство с LinkedIn, начиная с 1 марта 2019 года (когда будет выполнен переход от API LinkedIn v1 к v2).
3 ответа
Рассмотрение, что:
- понятие инкапсуляции об определении контейнера, и
- объектно-ориентированный дизайн основан на понятии передачи сообщений (вызов методов)
Я утверждал бы, что API является хорошим признаком об уместности новой высокоуровневой инкапсуляции (Т.е. определение нового объекта)
Если сервисы (т.е. API) предлагаемый этим новым объектом являются когерентными, и лучше подвергаются остальной части программы при перегруппировке в одном специальном объекте то любой ценой, используйте новый объект.
Иначе это вероятно излишество.
Так как Вы выставляете общедоступный API путем создания нового объекта, понятие теста может быть легче сделать в том новом объекте (и несколько других фиктивных объектов), вместо того, чтобы создать много объектов прежней версии для тестирования тех тех же операций.
В Вашем случае, если Вы хотите протестировать транзакцию, необходимо на самом деле протестировать MyEventHandler MyBoundaryClass для получения данных из UI.
Но если Вы определяете TransactionManager, который дает Вам возможность понизить связь различных уровней архитектуры (GUI по сравнению с данными) существующий в MyBoundaryClass и экспортировать управление данными в специализированный класс.
Затем можно протестировать персистентность данных в независимом сценарии тестирования, фокусируясь особенно на предельных значениях и отказе базы данных, и не - номинальные условия, и так далее.
Сценарий тестирования может помочь Вам совершенствовать сцепление (большой момент, упомянутый Daok) Ваших различных объектов. Если Ваши тесты являются простыми и когерентными, возможности состоят в том, что Ваши объекты имеют хорошо - определяют сервисную границу.
Так как можно утверждать, что Связь и Сцепление является двумя краеугольными камнями Программирования OO, сцепление нового класса как TransactionManager может быть оценено с точки зрения набора действий, которые это выполнит.
Связный означает, что определенный класс выполняет ряд тесно связанных действий. Отсутствие сцепления, с другой стороны, означает, что класс выполняет несколько несвязанных задач. [...] прикладное программное обеспечение в конечном счете станет неуправляемым, поскольку все больше поведений становится рассеянным и оказывается в неправильных местах.
При перегруппировке поведений, иначе реализованных в нескольких различных местах в TransactionManager он должен быть прекрасным, при условии, что его общедоступный API представляет ясные шаги того, что включает транзакция, и не "наполняют о транзакции" как различные служебные функции. Имени сам по себе недостаточно для оценки когезионной способности класса. Комбинация имени и его общедоступного API необходима.
Например, один интересный аспект TransactionManager состоял бы в том, чтобы полностью инкапсулировать понятие Транзакции, которая будет:
- станьте фактически unkown остальными f система, и понизил бы связь между другими классами и 'Транзакцию'
- укрепите когезионную способность TransactionManager путем центрирования ее API вокруг шагов транзакции (как initTransaction (), persistTransaction ()...), предотвращения любого метода считывания или метода set для любого экземпляра Транзакции.
При разработке предложение VonC рассмотрите следующие инструкции:
Если Вы ожидаете вызывать те же функции в другом месте, таким же образом, разумно инкапсулировать их в новом объекте.
Если одна функция (или один объект) предоставляет ряд услуг, которые полезны индивидуально, разумно осуществить рефакторинг его в меньшие компоненты.
Точка VonC о API является превосходным решающим испытанием: создайте эффективные интерфейсы, и объекты часто становятся очевидными.
Уровень инкапсуляции должен быть непосредственно связан со сцеплением Вашего объекта. Ваш объект должен сделать единственную задачу или должен быть разделен на несколько, классифицируют и инкапсулируют все ее поведения и свойства.
Эмпирическое правило - когда пора протестировать Ваш объект. Если Вы делаете Поблочное тестирование, и Вы понимаете тестирование нескольких другая вещь (не в том же действии области), чем Вы могли бы попытаться разделить его.
Поскольку Вы случаетесь, я инкапсулировал бы с Вашей идеей "TransactionManager". Таким образом, "TransactionManager" обработает, как транзакция работает и не "MyBoundaryClass".