Class Design C # Разделение пространства имен - PullRequest
Новая
       17

Class Design C # Разделение пространства имен

0 голосов
/ 10 марта 2009

Я все еще пытаюсь отработать разделение функций и то, как оно применяется к созданию классов и включению пространства имен. У меня есть собственный класс SoftwareComponent, который при представлении пользователю чаще всего отображается как ListItem. Является ли создание метода ToListItem хорошей идеей? Я волнуюсь, потому что теперь я поместил в класс зависимость, которая потребует включения пространства имен System.Web.UI.WebControls. 

    public ListItem ToListItem()
    {
        ListItem li = new ListItem();
        li.Text = ComponentName + " (+" + ComponentCost + ")";
        li.Selected = Selected;

        return li;
    }

Мое другое желание состоит в создании ListItem из SoftwareComponent на основе его свойств вне самого класса. Просьба высказать любые соображения о том, какой подход более уместен / лучше.

Ответы [ 3 ]

5 голосов
/ 10 марта 2009

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

public static class SoftwareComponentExtensions
{
    public static ListItem ToListItem(this SoftwareComponent component)
    {
        ListItem li = new ListItem(component.ComponentName + " (+" + component.ComponentCost + ")");
        li.Selected = component.Selected;

        return li;
    }
}
1 голос
/ 10 марта 2009

Я бы не знал SoftwareComponent о ListItems и тому подобном. Очевидно, кто-то должен знать, как взять SoftwareComponent и вставить его части в ListItem, но я думаю, что это не касается SoftwareComponent.

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

1 голос
/ 10 марта 2009

Похоже, SoftwareComponent - это доменный объект - объект, который описывает «вещь» в мире, в котором говорит ваше приложение.

Я стараюсь избегать зависимости этих объектов домена от чего-либо за пределами домена - это может быть более низкий уровень (как он хранится? Сериализуется ли он? Хранится в базе данных) или на уровне пользовательского интерфейса.

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

Для конкретной проблемы вы должны взглянуть на методы расширения C # 3.5. Они - ловкость рук в создании статических методов, которые выглядят так, как будто они определены в классе - если они не имеют доступа к частным / защищенным вещам (они могут получить доступ к общедоступным методам, как любой другой метод), вы можете обойтись без них , Я использую их для тех вещей, которые вы хотите сделать («методы» UI-уровня для объектов домена), которые определены в других местах.

Но имейте в виду, что методы расширения являются не чем иным, как синтаксическим сахаром для вас старых добрых статических методов в статическом классе.

...