Помощь с дизайном класса - PullRequest
Новая
       20

Помощь с дизайном класса

3 голосов
/ 13 февраля 2010

У меня есть класс, который должен взять информацию о продукте из базы данных одной системы и сохранить ее в базе данных продукта другой системы.

Я позвоню продукту из первой системы Продукт A и другой Продукт B. Данные продукта B зависят от настроек, выбранных пользователем.

Таким образом, у продукта B может быть метод GetDescription, который просматривает пользовательский параметр, который говорит, что использовать переменную Description1 из продукта A, или они могут выбрать описание 2, или они могут использовать описание уже в продукте B.

Это нормально, но есть много настроек и способов получить описание. Это проблема, у меня есть много методов, которые, кажется, все относятся к продукту B. Методы, такие как GetDescription, GetName, GetSku, которые все установлены в соответствии с настройками пользователя и все зависят от продукта A.

Хотя все они, похоже, относятся к продукту B, класс становится очень большим, и я хочу перенести некоторые методы из класса в другой класс. Я думал об использовании шаблона Factory. Нечто вроде ниже (код просто идея) 

public class ProductBuilder
{
    public ProductB BuildProduct()
    {
          SkuBuilder.BuildSku(ProductB,ProductA);
          ProductDescriptionBuilder.BuildDescription(ProductB,ProductA);
    }
}

Мои вопросы: каков хороший дизайн для этого? Является ли метод, предложенный мной выше, приемлемым? Видите ли вы какие-либо потенциальные проблемы с этим дизайном?

Ответы [ 2 ]

3 голосов
/ 13 февраля 2010

Это вариант шаблона factory , и это очень полезная форма дизайна. То, что вы написали, предлагает аккуратный трехклассный дизайн: ProductA, содержащий методы и свойства, относящиеся только к A, ProductB с методами и свойствами, относящимися к B, и ProductBuilder, который создает вам B на основе A.

Единственными подводными камнями этого являются общие проблемы проектирования ООП. Убедитесь, что ProductConverter не зависит от внутренних знаний о A или B - другими словами, убедитесь, что открытый интерфейс к A и B достаточно богат, чтобы ProductConverter мог выполнять свою работу. Только A должен подключаться к базе данных продуктов A, и только B должен подключаться к базе данных продуктов B. Избегайте одиночек и глобального состояния. Это вещи, которые вы бы делали практически в любом приложении, но они будут особыми ловушками в такой системе.

1 голос
/ 13 февраля 2010

Я бы предложил работать с абстракцией в вашем ProductBuilder, а не напрямую с ProductA и ProductB ... Таким образом, вы сможете безболезненно изменить реализацию позже. Использовать интерфейс или абстрактный класс ...

Также будет легче для тестирования и насмешек.

...