Новый шаблон проектирования execute()

[dech]

Наверное все используют шаблон construct(), основанный на рекомендациях Microsoft. Я придумал небольшое нововведение, позволяющее методы сделать более "чистыми".
Пример кода, как мы обычно строим RunBase-класс:

class ConstructTemplateDemo extends RunBase
{
    public static void main(Args _args)
    {
        ConstructTemplateDemo constructTemplateDemo = ConstructTemplateDemo::construct();
        ;
    
        if (constructTemplateDemo.init() && constructTemplateDemo.prompt())
        {
            constructTemplateDemo.run();
        }
    }

    public static ConstructTemplateDemo construct()
    {
        return new ConstructTemplateDemo();
    }
}

Видно, что и сам класс и его переменная занимают много места в тексте, кроме того в методе main() может также анализироваться _args, что усложнит логику метода и читать этот метод станет сложнее.
Прикинем, что можно сделать... Выделим содержимое метода main() в новый метод и посмотрим, что же у нас получилось:

class ExecuteTemplateDemo extends RunBase
{
    public static void main(Args _args)
    {
        ExecuteTemplateDemo::construct().execute();
    }

    public static ExecuteTemplateDemo construct()
    {
        return new ExecuteTemplateDemo();
    }

    public void execute()
    {
        if (this.init() && this.prompt())
        {
            this.run();
        }
    }
}

З.Ы. Критика приветствуется

[S.Kuskov]

Цитата:

Сообщение от dech

в методе main() может также анализироваться _args, что усложнит логику метода и читать этот метод станет сложнее

Обычно логику обработки _args выносят в отдельный метод this.initFromArgs(_args) и вызывают его из Main.

Как вы предлагаете работать с _args?

[dech]

Цитата:

Сообщение от S.Kuskov

Обычно логику обработки _args выносят в отдельный метод this.initFromArgs(_args) и вызывают его из Main.

Как вы предлагаете работать с _args?

Как вариант:

public void execute(Args _args)
{
    this.initFromArgs(_args);
    if (this.init() && this.prompt())
    {
        this.run();
    }
}

[twilight]

Не вижу особых преимуществ. Общее количество строк не изменилось, а вот методов стало больше.

[Raven Melancholic]

Ну уж если поворчать, то в DAX4 и DAX2009 Microsoft рекомендует использовать не construct напрямую, а методы newЧего-то-там, а construct делать защищенным, причем в конструкторе только создавать экземпляр класса, не устанавливая никаких параметров (в BP даже есть проверка на это).
А вот в методах new* и делать инициализацию из параметров.

[belugin]

См также SysOperation framework в 2012

[S.Kuskov]

Цитата:

Сообщение от twilight

Общее количество строк не изменилось, а вот методов стало больше.

Можно такой метод execute (включающий в себя наиболее распространённую и правильную комбинацию действий) поместить в базовый класс. Тогда его не нужно будет повторять на каждом наследнике. В результате кода и методов станет меньше.

Но согласен. Сверхполезным такое нововведение я бы не назвал.
Выбирая между красивым кодом и стандартным я бы выбрал стандартный.

[dech]

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

Цитата:

Сообщение от belugin

См также SysOperation framework в 2012

Посмотрим