Правильная практика ООП для свойств класса, связанных логикой - PullRequest
0 голосов
/ 23 ноября 2011

У меня есть класс под названием documentsection, который определяет часть документа, которая впоследствии собирается в HTML.В нем есть свойства, и то, какие значения являются обязательными (или действительными), зависит друг от друга.Например:

a) Существует перечисление, называемое «тип раздела», которое может быть «видом» (в этом случае другое свойство, называемое «содержимое», содержит путь / имя файла для чтения файла).Или это может быть «текст», в котором текст свойства «контент» сам размещен в документе.

b) Существует еще одно перечисление, называемое «Действие», которое может иметь тип «добавление», «добавление» или «замена».В последнем случае релевантным становится другое свойство, называемое «tagtoreplace».Если мы добавляем / добавляем, это свойство tagtoreplace может быть пустым.

Каков наилучший способ представления таких взаимозависимостей?Есть несколько способов, которые я могу придумать, но ни один из них не пахнет красотой:

  • Когда вызывается метод для «генерации документа», просмотрите свойства, чтобы убедиться, что они соответствуют этомулогика.

  • Поставьте проверки в методах get / set.Одна из проблем заключается в том, что, когда я устанавливаю свой тип раздела «view», я не могу установить свое свойство «content» до строки или около того после этого, поэтому вы не можете отклонить запрос на установку этого параметра в этом месте.

  • Используйте отдельные свойства, чтобы как-то разделить области применения - например, «контент» в моем первом примере выше не должен использоваться для пути к файлу в одном случае, а набор содержимого HTML - в другом.Мне это не кажется правильным, но наличие отдельных свойств для каждого из них кажется чрезмерным.

  • Наследовать подклассы, каждый из которых имеет различные наборы дополнительных необходимых свойств.Поскольку могут быть различные комбинации типа раздела и типа действия, я не могу придумать элегантного способа внедрить всю эту логику в такую ​​структуру.Но я не гуру ООП!

Есть мысли о лучшем подходе?

Спасибо!

Ответы [ 4 ]

2 голосов
/ 23 ноября 2011

Я бы пошел со следующим подходом:

interface ISection 
{
    void Render(); // or String Render() if you want to return a string
}

class ViewSection : ISection
{
    public String Filename { get; set; }

    public void Render()
    {
        // do stuff with Filename and/or return the content of the file
    }
}

class TextSection : ISection
{
    public String Text { get; set; }

    public void Render()
    {
        // do stuff with Text and/or return it
    }
}

class DocumentSection
{
    ISection _section;

    public void Render()
    {
        _section.Render();
    }
}

Затем вы можете легко создавать новые классы, реализующие ISection, которые предоставляют дополнительные разделы. То же самое касается «действий», определите интерфейс IAction с помощью метода Render или PerformAction, который вы вызываете.

1 голос
/ 23 ноября 2011

Я бы отделил генерацию HTML от самой генерации документа.Иметь классы, используемые для определения документа, а затем другие классы, используемые для генерации каждого раздела документа.Таким образом, вы можете легко добавлять новые форматы позже (или проще создавать тестовый документ или генерировать html)

a) Существует перечисление под названием «тип раздела», которое может быть «видом» (в этом случае другое свойство с именем 'content' содержит путь / имя файла для чтения).Или это может быть «текст», в котором текст свойства «контент» сам размещен в документе.

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

b) Существует еще одно перечисление, называемое «Action», которое может иметь тип «append», «prepend» или «replacebytag».В последнем случае релевантным становится другое свойство, называемое «tagtoreplace».Если мы добавляем / добавляем, это свойство tagtoreplace может быть пустым.

Мне непонятно, как вы используете свойство action.

1 голос
/ 23 ноября 2011

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

Если вы хотите сделать что-то подобное, вы должны использовать метод, чтобы установить все сразу.

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...