Являются ли «пассивные» объекты хорошей дизайнерской практикой?

Question

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

Я называю этот тип объектов "пассивными" объектами - объектами, для которых не определены общедоступные методы. Все взаимодействие происходит внутри них в приватных методах и событиях аргументов, передаваемых в конструктор.

Обычно это какой-то служебный класс, например, такой, который гарантирует, что две формы будут склеены:

public class StickyForm : IDisposable
{
    private readonly Form form;
    private readonly Form parentForm;

    public StickyForm(Form form, Form parentForm)
    {
        this.form = form;
        this.form.StartPosition = FormStartPosition.Manual;
        this.parentForm = parentForm;

        this.parentForm.LocationChanged += new EventHandler(parent_LocationChanged);
        this.parentForm.SizeChanged += new EventHandler(parent_SizeChanged);

        SetLocation();
    }

    void parent_SizeChanged(object sender, EventArgs e)
    {
        SetLocation();
    }

    void parent_LocationChanged(object sender, EventArgs e)
    {
        SetLocation();
    }

    private void SetLocation()
    {
        //compute location of form based on parent form 
    }

    public void Dispose()
    {
        this.parentForm.SizeChanged -= parent_SizeChanged;
        this.parentForm.LocationChanged -= parent_LocationChanged;
    }
}

Но иногда это также своего рода контроллер, обеспечивающий взаимодействие между двумя представлениями:

public class BrowseController
{
    private IBrowserView view;
    private IFolderBrowser folderBrowser;

    public BrowseController(IFolderBrowser folderBrowser, IBrowserView view)
    {
        this.view = view;
        this.folderBrowser = folderBrowser;

        this.folderBrowser.NodeOpened += folderBrowser_NodeOpened;
    }

    private void folderBrowser_NodeOpened(object sender, Core.Util.TEventArgs<IPictureList> e)
    {
        this.Browse(e.Value);
    }

    public void Browse(IPictureList content)
    {
        //stripped some code
        AddItemsToView(content);
    }

    private void AddItemsToView(IPictureList browser)
    {
        //call methods on view
    }
}

Считают ли такие "пассивные" объекты хорошей практикой проектирования?

Есть ли лучшее название для этого класса?

Answer 1

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

Как насчет названия "контроллер". «контроллер» - более обычное имя для класса, используемого в пользовательском интерфейсе, которое вызывает взаимодействие между представлением и данными, и им часто не нужно иметь публичные методы.

Я уверен, что есть другие идеи для имен.

Answer 2

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

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

Answer 3

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

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

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

Answer 4

Я не вижу в этом ничего плохого. Если это приводит к чистому читаемому коду, сделайте это!

Answer 5

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

ОБНОВЛЕНИЕ: чтобы прояснить, что я имею в виду, рассмотрим два (или более) класса, полученных из StickyForm

public class VeryStickyForm : StickyForm
{
//some implementation here
//but interface is completely inherited from StickyForm
}
public class SomewhatStickyForm : StickyForm
{
//some implementation here
//but interface is completely inherited from StickyForm
}

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