Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, bl-blx, Вы писали:

BB>>

BB>>interface ICar {
BB>>   void Move();
BB>>}

BB>>class Car : ICar {
BB>>    class NonMovable : ICar {
BB>>        [EditorBrowsable(EditorBrowsableState.Never)]
BB>>        void Move();
BB>>    }
BB>>    class MovableCar : ICar {
BB>>        [EditorBrowsable(EditorBrowsableState.Always)]
BB>>        void Move();
BB>>    }
BB>>    private ICar _state;

BB>>    ICar State { get; }
BB>>}
BB>>

А>Да, и еще, человек жаловался, что ему придется на каждый метод типа Move делать свойство типа CanMove.

А>Вы ему резко упростили задачу: теперь ему придется реализовать N * (N — 1) классов, где N — число свойств.

А>MovableSaleableCar
А>NonMovableSaleableCar
А>MovableNonSaleableCar
А>NonMovableNonSaleableCar

Я так понимаю, мы говорим о классах, описывающих представление в UI, все-таки?
А их как бы по количеству юз-кейзов конечное число.
Все равно это где-то придётся описать хотя бы раз. Почему не в коде?

Здравствуйте, Аноним, Вы писали:

А>Вы ему резко упростили задачу: теперь ему придется реализовать N * (N — 1) классов, где N — число свойств.

Что-то я тут перепутал. 2^N же классов.

Здравствуйте, bl-blx, Вы писали:

BB>Да ржите сколько угодно. Вам еще, небось, компилируемый код подавай, чтоб понятнее было?
BB>Аннотации-то куда пропали?

Извините, это не насмешка над вами, просто смешно получилось — "Non-movable car". Это какая-то абсурдная сущность, вам не кажется? Сущности с подобным названием, мне кажется, часто говорят об избыточной архитектуре.

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

Плюс, непонятно, что делать с остальными свойствами/методами класса Car.

Здравствуйте, bl-blx, Вы писали:

BB>Я так понимаю, мы говорим о классах, описывающих представление в UI, все-таки?
BB>А их как бы по количеству юз-кейзов конечное число.
BB>Все равно это где-то придётся описать хотя бы раз. Почему не в коде?

Число-то конечное, но их же 2^N. Восемь свойств дадут 256 классов. Вы серьезно хотите заставить автора темы реализовывать такое бешеное число классов ради решения такой ничтожной проблемы?

MovableSaleableCar
NonMovableSaleableCar
MovableNonSaleableCar
NonMovableNonSaleableCar

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, bl-blx, Вы писали:

BB>>Да ржите сколько угодно. Вам еще, небось, компилируемый код подавай, чтоб понятнее было?
BB>>Аннотации-то куда пропали?

А>Извините, это не насмешка над вами, просто смешно получилось — "Non-movable car". Это какая-то абсурдная сущность, вам не кажется? Сущности с подобным названием, мне кажется, часто говорят об избыточной архитектуре.

Это было абстрактное обозначение состояния, в котором к машине не применим метод Move().

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

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

А>Плюс, непонятно, что делать с остальными свойствами/методами класса Car.

А что с ними надо делать? Я так понимаю, в системе есть вполне определенные состояния
для этой сущности. В каждом из состояний возможны или не возможны какие-то операции,
доступны или не доступны отдельные свойства. Не нравятся конкретные классы? Можно
оставить наследование интерфейсов с аннотациями. Получится mix-in подход.

И, повторюсь, возможен другой вариант, тоже на аннотациях:

interface ICar {
    enum {
        ST1, // abstract state where car is not movable
        ST2, // abstract state where car is movable
        ST3,
        ...
    } State;

    [AllowedIn(State.ST2, State.ST3)]
    void Move();

    [AllowedIn(State.ST3)]
    void Sell();
}

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, bl-blx, Вы писали:

BB>>Я так понимаю, мы говорим о классах, описывающих представление в UI, все-таки?
BB>>А их как бы по количеству юз-кейзов конечное число.
BB>>Все равно это где-то придётся описать хотя бы раз. Почему не в коде?

А>Число-то конечное, но их же 2^N. Восемь свойств дадут 256 классов. Вы серьезно хотите заставить автора темы реализовывать такое бешеное число классов ради решения такой ничтожной проблемы?

А>MovableSaleableCar
А>NonMovableSaleableCar
А>MovableNonSaleableCar
А>NonMovableNonSaleableCar

Зачем столько?
Есть валидные состояния с точки зрения бизнес-логики, когда Car не может
выполнять операцию Move(). Их конечное число по числу состояний жизненного
цикла Car, но, отнюдь, не 2^N.
Например (хотя смешивать Move() и Sale() как-то странно):
InSales[+Move(), +Sale()],
InTransit[+Move(), -Sale()].

Здравствуйте, bl-blx, Вы писали:

BB>И, повторюсь, возможен другой вариант, тоже на аннотациях:
BB>

BB>interface ICar {
BB>    enum {
BB>        ST1, // abstract state where car is not movable
BB>        ST2, // abstract state where car is movable
BB>        ST3,
BB>        ...
BB>    } State;

BB>    [AllowedIn(State.ST2, State.ST3)]
BB>    void Move();

BB>    [AllowedIn(State.ST3)]
BB>    void Sell();
BB>}
BB>

На аннотациях — годное решение, только "состояния" не нужны. Я по секрету вам скажу, что любой объект является конечным автоматом, множество состояний которого изоморфно подмножеству декартова произведения состояний его полей. Аналогично любая программа, имеющая состояние, является конечным автоматом. Вот только явно эти состояния выписывать нет никакой нужды, да и нереально это, так как в любой даже не очень сложной программе их умопомрачительное количество. Но главное, что это не нужно.

Конечный автомат — это математическая модель, не надо пытаться его в явном виде вручную конструировать. Сетевую структуру человеческий разум плохо воспринимает. Конечные автоматы надо выражать в древовидном представлении — "разделять и властвовать", чем, собственно, структурное программирование и его производные последние несколько десятков лет и занимаются.