Здравствуйте! Новичок С++.
Интересуют следующие вопросы
1. Как вообще в ООПрограммировании называется ситуция, когда
у экзепляра некоторого класса при изменении какого-то свойства X на "фиксированное" значение v_x1 (все значения могут быть только фиксированными)
автоматически должны измениться свойства XA, XB, XC и т.д. на свои конкретные "фиксированные" значения v_xa1, v_xb1, v_xc1.
Всего вариантов возможных значений у указанных свойст может быть нескольно, но в зависимости от ключевого свойства X остальные выставляются в свои предопределенные значения.
Как бы получается объект может быть в строго определенном состоянии, которое и характеризуется указаными свойствами.
Это немного похоже на соблюдение целостности данных в БД.
2. Как ситуация из п.1 называется С++ и как она в нем реализуется?

Также подскажите пожалуйста, где это можно почитать?

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

А>Также подскажите пожалуйста, где это можно почитать?
возможно, это не то, но всё же
http://en.wikipedia.org/wiki/Reactive_programming

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

А>Здравствуйте! Новичок С++.
А>Интересуют следующие вопросы
А>1. Как вообще в ООПрограммировании называется ситуция, когда
А>у экзепляра некоторого класса при изменении какого-то свойства X на "фиксированное" значение v_x1 (все значения могут быть только фиксированными)
А>автоматически должны измениться свойства XA, XB, XC и т.д. на свои конкретные "фиксированные" значения v_xa1, v_xb1, v_xc1.

Похоже на КА (Конечный Автомат). Но ни к C++, ни к ООП это непосредственного отношения не имеет.

L>Похоже на КА (Конечный Автомат).

ну, в принципе, любой класс не выделяющий память в куче -- это конечный автомат

Если я правильно понял, то в твоем случае можно использовать паттерн состояние. Вот простой пример:

class Calendar
{
public:
    enum Days
    {
        Day_Sunday = 0,
        Day_Monday
    };

    void SetDay(Days currentDay)
    {
        switch (currentDay)
        {
            case Day_Sunday: CurrentDay_.reset(new Sunday()); break;
            case Day_Monday: CurrentDay_.reset(new Monday()); break;
        };
    }

    bool IsHoliday() const { return CurrentDay_->IsHoliday(); }

private:
    struct Day
    {
        virtual ~Day() {}
        Day(bool isHoliday) : IsHoliday_(isHoliday) {}
        bool IsHoliday() const { return IsHoliday_; }

    private:
        const bool IsHoliday_;
    };

    struct Sunday : public Day { Sunday() : Day(true) {} };
    struct Monday : public Day { Monday() : Day(false) {} };

    boost::scoped_ptr<Day> CurrentDay_;    
};

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

А>Здравствуйте! Новичок С++.
А>Интересуют следующие вопросы
А>1. Как вообще в ООПрограммировании называется ситуция, когда
А>у экзепляра некоторого класса при изменении какого-то свойства X на "фиксированное" значение v_x1 (все значения могут быть только фиксированными)
А>автоматически должны измениться свойства XA, XB, XC и т.д. на свои конкретные "фиксированные" значения v_xa1, v_xb1, v_xc1.
А>Всего вариантов возможных значений у указанных свойст может быть нескольно, но в зависимости от ключевого свойства X остальные выставляются в свои предопределенные значения.
А>Как бы получается объект может быть в строго определенном состоянии, которое и характеризуется указаными свойствами.
А>Это немного похоже на соблюдение целостности данных в БД.
А>2. Как ситуация из п.1 называется С++ и как она в нем реализуется?

А>Также подскажите пожалуйста, где это можно почитать?

Если я правильно понял, то такая ситуация называется "инкапсуляция". Реализуется очень просто: делаешь закрытыми все свойства объекта, а доступ и изменение к ним осуществляешь через функции. Общепринятыми для этих целей считаются функции под именами put/get. Но можно применять и любые другие, главное сам не запутайся. Если проводить анологию с БД, то такие функции в неготором роде можно назвать тригерами. Соответственно в этой функции анализируешь новое значение и на его основе присваиваешь остальным свойствам нужные значения.

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

Вам следует копать в сторону FMM(finite message mashine)/FSM(finite state mashines). К слову сказать: сама суть программирования — построение логики этих машин, в зависимости от задачи. ООП лишь позволяет выполнить это с большим уровнем абстракции в отличие от функционального программирования.
Следует отметить что существуют т.н. патерны явно связанные с этой парадигмой: например command, signal-slot и.т.п.

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

ZS>Если я правильно понял, то такая ситуация называется "инкапсуляция". Реализуется очень просто: делаешь закрытыми все свойства объекта, а доступ и изменение к ним осуществляешь через функции. Общепринятыми для этих целей считаются функции под именами put/get. Но можно применять и любые другие, главное сам не запутайся. Если проводить анологию с БД, то такие функции в неготором роде можно назвать тригерами. Соответственно в этой функции анализируешь новое значение и на его основе присваиваешь остальным свойствам нужные значения.

Вы правильно поняли.
Получается в каком либо ,напр., входном интерфейсе get(xtype inX), достаточно правильно обработать
получение параметра inX для инкапсулированного св-ва X со всеми вытекающими последствиями (установка "нужных" значений зависимых свойств XA, XB, XC).

Но достаточно ли только этого? У Страутрупа в таких ситуациях применяется понятие инварианта, и всяческих сопуствующих ему
проверок\установок (собственно это немного и сбило с толку ) Хотелось бы прояснить это.

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

I>Получается в каком либо ,напр., входном интерфейсе get(xtype inX), достаточно правильно обработать
I>получение параметра inX для инкапсулированного св-ва X со всеми вытекающими последствиями (установка "нужных" значений зависимых свойств XA, XB, XC).

Как раз так делать не надо.
Интерфейс get() не должен менять состояние объекта. Он должен быть объявлен const, что работать, например, с константными ссылками.
Менять состояние объекта надо только в сеттере (методе set(X)). Соответственно, у тебя будет один сеттер (для Х) и четыре геттера (для Х, А, В и С).

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

C>Здравствуйте, igua, Вы писали:

I>>Получается в каком либо ,напр., входном интерфейсе get(xtype inX), достаточно правильно обработать
I>>получение параметра inX для инкапсулированного св-ва X со всеми вытекающими последствиями (установка "нужных" значений зависимых свойств XA, XB, XC).

C>Как раз так делать не надо.
C>Интерфейс get() не должен менять состояние объекта. Он должен быть объявлен const, что работать, например, с константными ссылками.
C>Менять состояние объекта надо только в сеттере (методе set(X)). Соответственно, у тебя будет один сеттер (для Х) и четыре геттера (для Х, А, В и С).

Прошу прощения, что ввел вас в заблуждение!
Очепятка вышла — там где у меня get написано должно было быть set — интерфейс то ВХОДНОЙ.
Получается этот вопрос решен. В любом случае спасибо за помощь и внимание!

On 22.02.2011 19:41, Аноним wrote:

> 1. Как вообще в ООПрограммировании называется ситуция, когда
> у экзепляра некоторого класса при изменении какого-то свойства X на
> "фиксированное" значение v_x1 (все значения могут быть только фиксированными)
> автоматически должны измениться свойства XA, XB, XC и т.д. на свои конкретные
> "фиксированные" значения v_xa1, v_xb1, v_xc1.
> Всего вариантов возможных значений у указанных свойст может быть нескольно, но в
> зависимости от ключевого свойства X остальные выставляются в свои
> предопределенные значения.

Это функциональная зависимость всех этих атрибутов от X.

> 2. Как ситуация из п.1 называется С++ и как она в нем реализуется?

Я не знаю, как она реализуется, я могу сказать, как её реализовать.
Таблица (map например), ключ -- значение X, значение -- структура
со всеми этими полями XA, XB, XC. При этом XA, XB, XC в самом объекте
хранить не надо, надо только X хранить. XA, XB, XC получаются из
этой мапы и возвращаются наружу класса.

Таким образом экономиш память sizeof( XA, XB, XC ) * (кол-во экземпляров
класса — кол-во экземпляров класса с уникальными атрибутами).

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

А>1. Как вообще в ООПрограммировании называется ситуция, когда
А>у экзепляра некоторого класса при изменении какого-то свойства X на "фиксированное" значение v_x1 (все значения могут быть только фиксированными)
А>автоматически должны измениться свойства XA, XB, XC и т.д. на свои конкретные "фиксированные" значения v_xa1, v_xb1, v_xc1.
А>Всего вариантов возможных значений у указанных свойст может быть нескольно, но в зависимости от ключевого свойства X остальные выставляются в свои предопределенные значения.
А>Как бы получается объект может быть в строго определенном состоянии, которое и характеризуется указаными свойствами.

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

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

MZ>Я не знаю, как она реализуется, я могу сказать, как её реализовать.
MZ>Таблица (map например), ключ -- значение X, значение -- структура
MZ>со всеми этими полями XA, XB, XC. При этом XA, XB, XC в самом объекте
MZ>хранить не надо, надо только X хранить. XA, XB, XC получаются из
MZ>этой мапы и возвращаются наружу класса.

MZ>Таким образом экономиш память sizeof( XA, XB, XC ) * (кол-во экземпляров
MZ>класса — кол-во экземпляров класса с уникальными атрибутами).

Память действительно экономится, а как же сокрытие данных, т.е. упомянутая ранее инкапсуляция?

On 25.02.2011 19:38, igua wrote:
> Память действительно экономится, а как же сокрытие данных, т.е. упомянутая ранее
> инкапсуляция?

А я разве предлагал что0-то из данных открывать ?

MasterZiv, Вы писали:

Таблица (map например), ключ -- значение X, значение -- структура
со всеми этими полями XA, XB, XC. При этом XA, XB, XC в самом объекте
хранить не надо, надо только X хранить. XA, XB, XC получаются из
этой мапы и возвращаются наружу класса.

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

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

I>Но с другой, класс уже не несет ответственности за данные, к-е хранятся вне него. Понятно, что конечная ответственость за корректность манипуляций с данными лежит на разработчике, но все же риск изменения данных больше, чем у тех, что внутри класса. Или я что-то не учел?

Расскажи свою задачу более понятно. А то есть такое чувство, что ты чего-то не договариваешь. Например, из твоего описания не ясно зачем вообще хранить "производные" данные в каждом экземпляре класса...

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

I>

Таблица (map например), ключ -- значение X, значение -- структура
I>со всеми этими полями XA, XB, XC. При этом XA, XB, XC в самом объекте
I>хранить не надо, надо только X хранить. XA, XB, XC получаются из
I>этой мапы и возвращаются наружу класса.

I>Получается таблица не хранится в классе — с одной стороны это хорошо — экономится память, как вы и сказали.
Таблица может храниться, например, в статическом поле класса. Тогда она будет "в классе", но не в каждом экземпляре класса будет по копии таблицы...

Расскажи про свою задачу подробнее. Тебе проще будет советы давать... А то так телепатия маленько требуется

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

E>Расскажи про свою задачу подробнее. Тебе проще будет советы давать... А то так телепатия маленько требуется

Задача следующая:
Есть сущность СпецСтрока, у которой есть разные свойства формата, например: негатив_режим, режим_курсив, ...,
и режим_габаритов == Маленькие(s_m1 х s_n1 пикс.) и Большие(s_m2 х s_n2 пикс.) символы в строке.
Есть Дисплей D_m х D_n пикс. Дисплей может содержать столько СпецСтрок, сколько позволит его разрешение,
причем у них может быть разный режим_габаритов, например q Больших и p Маленьких строк,
по одному горизонтальному ряду на СпецСтроку вне зависимости от ее габаритов.

Вопрос мой касался управления режимом_габаритов и подчиненных ему свойств.
Если абстрактно, то есть зависимость: ключевое свойство -- зависимые свойства.

Проанализировав все способы решения, решил использовать споcоб предложенный вами:

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

Будут ли какие-то замечания по этому поводу?

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

А>1. Как вообще в ООПрограммировании называется ситуция,

По-моему никак. Всего лишь одна из бесконечного множества ситуаций, не вижу в ней ничего особенного.

Что тебя смущает — что некоторые свойства не соответствуют 1:1 полям данных в реализации? Они и не должны соответствовать. Свойство может брать свое значение из аггрегируемого класса, возвращать (int)(this)*7 или быть write-only, нечитаемым. Свойство не более чем метод, тебя же не смущает, что три метода xa() xb() xc() могут вычислять свои результаты из одного поля данных, почему тебя смущает тоже самое у свойств?

А>2. Как ситуация из п.1 называется С++ и как она в нем реализуется?

Тем более что в C++ нет свойств, у тебя будет просто набор методов.

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

I>Проанализировав все способы решения, решил использовать споcоб предложенный вами:
I>

I>Если я тебя верно понял, то у тебя бывает всего несколько наборов значений. Тогда логичнее сделать так, чтобы на каждый набор было по константному объекту, а состояние задавалось не перечислением, а указателем на один из таких объектов...

I>Будут ли какие-то замечания по этому поводу?

Да нет, это логичный и стандартный, в общем-то подход. Называется "таблица стилей". Типа у строки/слова/буквы есть указатель на стиль, а в стиле уже хранятся всякие подробности чего там и как выводить. В качестве доп. бонуса получаем возможность крутить стиль сразу всех строк...