Каков будет правильный дизайн для упаковки существующей библиотеки? - PullRequest
1 голос
/ 09 ноября 2011

Я выполнил пару небольших личных проектов в .NET, и, следуя советам по SO, решил сделать что-то более продвинутое, чтобы я мог учиться по ходу дела.

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

В сторонней библиотеке, Я концентрируюсь на одном объекте, давайте назовем его DataSource, и это, в свою очередь, содержит результаты, относящиеся к базе данных.Для небольшого примера (объекты здесь имеют гораздо больше методов и свойств, которые не показаны), у этого есть «дерево» свойств следующим образом:

A_DataSet -> A_Result -> A_Dimensions() -> A_Dimension -> A_SetDisplayType(DisplayAs)

Здесь ResultОбъект имеет свойство с именем Dimensions, которое содержит коллекцию Dimension.Наконец, у каждого Dimension есть метод с именем SetDisplayType, который управляет отображением данных, содержащихся в другом свойстве в Dimension.Элементы имеют префикс A_ только для целей этого примера.

Теперь, поскольку методы и свойства сторонней библиотеки иногда не понятны в использовании и многочисленны по своей природе, я хотел создать «оболочку»"к этой библиотеке, чтобы я упростил ее использование и структуруПосле недолгих размышлений о том, как более логически сгруппировать элементы, я подумал о том, чтобы перейти в следующем направлении со структурой:

B_DataSet -> B_Dimensions() -> B_Dimension -> B_DisplayProperties -> B_SetDisplayType(DisplayAs)

В этом примере я поставил перед объектами префиксB_ просто чтобы отличить их от существующих элементов выше, конечно, это не окончательное соглашение об именах (на самом деле наименование не имеет большого значения для целей этого вопроса).

Дело в том, что я застрялЭто то, как я должен правильно ссылаться на сторонние объекты (A_ *) из класса оболочки.Например, если бы я хотел использовать B_SetDisplayType, это вызвало бы внутренний вызов A_SetDisplayType.Тем не менее, поскольку A_SetDisplayType принадлежит A_Dimension, мне потребуется ссылка на A_Dimension в B_DisplayProperties.Это нормально при создании объектов, чтобы передать им ссылку на своего «родителя» в конструкторе?Я думал о чем-то вроде следующего кода:

Public Class DataSetDisplayProperties

    Private _A_Dimension as A_Dimension

    Public Sub New(MyDimension as A_Dimension)

        _A_Dimension = MyDimension

    End Sub

    Public Sub B_SetDisplayType(DisplayAs as Integer)

        Call _A_Dimension.A_SetDisplayType(DisplayAs)

    End Sub

End Class

Кажется ли это хорошо, или есть лучший способ?

Я думал об использовании фасада, но не знал, какэто будет работать, когда я пытаюсь сослаться на методы на разных «уровнях» на существующую структуру.

Обратите внимание, что я не могу наследовать ни от одного из сторонних классов и не могу изменить их код.

Извинения, если вышеизложенное кажется немного запутанным, я думаю, что, возможно, я не знаю правильной терминологии для того, как выразить мою проблему.Спасибо!

1 Ответ

0 голосов
/ 09 ноября 2011

Может показаться, что это не ответ на этот вопрос, конечно, не прямой, но оставайтесь со мной. Прежде всего, я думаю, что вы правы, когда говорите, что хотите построить Фасад. Могу ли я предложить вам использовать подход Test Driven Development для разработки интерфейса для этого фасада, а затем вы можете сосредоточиться на том, как реализовать этот интерфейс с помощью сторонней библиотеки. Это позволит вам очистить свой разум от особенностей и именования сторонней библиотеки и сосредоточиться исключительно на интерфейсе, который вы хотите предоставить, и на том, чего вы хотите добиться. Это также приведет к созданию модульного теста для вашей реализации Facade.

Если вы раньше не использовали TDD, значит, у вас есть довольно сложный путь, но я могу заверить вас, что это стоит вложений. Что касается инструментов, я рекомендую NUnit и MOQ. Вам также может понадобиться контейнер IoC, например Unity 2.0.

Удачи!

...