Чтобы обернуть или не обернуть

Я думаю, что это довольно субъективный вопрос, поэтому я приведу конкретный пример.Чтобы обернуть или не обернуть

Рассматривая дизайн набора классов-оболочек для обертывания доступа к информации WMI с использованием пространства имен System.Management, у меня возникла проблема, когда я начал задаваться вопросом, как я мог бы удовлетворить ситуации, когда необходимо одноразовое значение, скажем, Серийный номер BIOS от Win32_BIOS, а также в ситуациях, когда может потребоваться много разных свойств или более сложных поисков, например, поиск файлов в CIM_DataFile.

Это заставило меня задуматься над тем, действительно ли идея обернуть функциональность, подобную представленной в пространстве имен System.Management, или же в конце я добавлю излишне сложные и длинные классы-оболочки во имя уменьшения суммы кода в приложении.

Каково общее согласие с этой проблемой, стоит ли писать сложные классы-оболочки в надежде сэкономить время или лучше просто придерживаться гибкости встроенных классов, даже если это иногда не кажется особенно чистым или опрятным.

источник

2014-01-22 Ashigore

+1 для приятного заголовка –

Вы заботитесь о том, чтобы высмеивать классы, которые вы обертываете? Если да, то да. –

Этот вопрос может быть лучше подходит для http://programmers.stackexchange.com/ –

Цель класса-оболочки - скрыть сложную функциональность от вызывающего.

Другими словами, если все вызывающее приложение хочет сделать, это узнать серийный номер, тогда он должен просто вызвать что-то вроде myobj.GetSerialNumber(), что сделало бы все вызовы WMI необходимым для возврата этого значения.

Однако, если вызывающее приложение уже находится в коленном углублении в WMI или, если вы обнаружите, что имитируете работу WMI с незначительными изменениями, лучше не переносить его и позволить вызывающему приложению делать свою работу.

источник

2014-01-22 17:20:48 NotMe

Я нахожу, что это имеет для меня большой смысл, но когда я это делаю, я начинаю думать, что должен действительно сделать такие обертки в повторно используемые библиотеки и сложные снежки оттуда. – Ashigore

@Ashigore: данная база кода должна быть настолько сложной, насколько это необходимо для решения проблемы, с которой вы столкнулись. Другими словами, сделайте его только как можно многократно используемым для решения вашей текущей проблемы. Если позднее вы обнаружите, что ваш код может быть повторно использован в другом приложении, то вы его реорганизуете. На самом деле существуют редкие ситуации, в которых изначально строится для повторного использования ... а именно, когда у вас уже есть несколько систем, со спецификациями, о которых вы знаете, будут пользоваться преимуществами. – NotMe

Основная причина, по которой я говорю, это то, что у вас нет НИКАКОГО представления о требованиях к будущим системам. Из-за этого у вас абсолютно нет идеи о том, какие функции им могут понадобиться. Это означает, что независимо от того, вы все равно будете реорганизовывать свою библиотеку. Лучше держать его простым и ввести сложность только тогда, когда это необходимо; и даже тогда только ввести требуемую сложность. – NotMe

Чтобы обернуть или не обернуть

ответ

Смежные вопросы