Базовые и порожденные классы

[Джон]

To Джон.
А какая с Вашей точки зрения должна быть структура объектов в следующей задаче - в соответствием с ООП.
Обработка данных о людях. Естественно у женщин и мужчин есть как много общих данных\функций\алгоритмов, так и исключительно специфических. Мне хотелось бы иметь для них 2 разных класса. Мне кажется очевидным использовать для общих данных и функций базовый класс. Вопрос - как хранить данные о людях, если основная обработка связанна с общими функциями, а специфика проявляется изредка в частных случаях. Например - поликлиника. 80% болячек общие, но иногда необходимо выполнить исключительно женские или мужские проверки. Вести параллельно 2 массива или 1.  А если 1, то как перейти к специфике?

ezus, немного непривычно - холодно подчёркнутое "Вы", лично мне гораздо приятней дружеское "ты". Но как угодно. Сорри зы "тыканье" в предыдущих постах.

Итак, к Вашему вопросу. Конечно же один массив объектов одного типа - Больные. Совершенно верно - общие поля в базовом классе, а индивидуальные в наследуемых - мужчины, женщины, дети. Например, под индивидуальностью можно назвать посещение врачей - гинеколога, педиатра и "мужолога" (не могу придумать спец. врача для мужуков). Каждого пациета в списке надо отправить к своему врачу. "Вашим" (условно) методом, кажый производный класс получает ф-ю ПосетитьГинеколога(), ПосетитьПедиатра() и тд, потом следует приведение типа (Женщина*), (Ребёнок*) и вызов ф-ции.
Гораздо удобней (также для последующего использования) определить виртуальную ф-ю ПосетитьВрача()=0. Обратите внимание. Физически ничего не изменяется. Каждый объект-наследник получает как и в "Вашем" способе (ещё раз - название чисто условное, чтобы различать) одну специальную ф-ю. Единственно отличие - одна дополнительная строчка в базовом классе. Как видите, никаких лишних ф-ций. Зато какое это даёт преимущество! Допустим, в будущем состав больных придётся расширить. ДОбавяться пожилые, студенты, безнадёжно больные и тп. Как в этом случае будет выглядеть вызов ф-ций в цикле обработки списка? Помните, я привёл пример-объяснение нелепости в #21? И эта "этажерка" вместо одой строчки? Причём надо НЕ ЗАБЫТЬ это сделать!!! В случе с чисто виртуальным методом этого не произойдёт в принципе. Вот и вся "заморочка". Суть остаётся - в цикле обработки списка объектов должно что-то произойти, некое действие. Значит всё сводится к семантике метода, но тут разработчику предоставлена полная свобода выбора.

[Джон]

И все-таки может быть кто-нибудь знает - как избежать предупреждения

warning C4541: 'dynamic_cast' used on polymorphic type 'class Keta' with /GR-; unpredictable behavior may result

?

Какая ОСь? Какая студия? Тип проекта? Как выполнялись настройки проекта - вручную или приняты по умолчанию?

[Джон]

Вот что говорит MSDN

Compiler Warning (level 1) C4541
'identifier' used on polymorphic type 'type' with /GR-; unpredictable behavior may result

You tried to use a feature that requires run-time type information without enabling run-time type information. Recompile with /GR.

[Dimka]

Я же отметил, что это ПРИНЦИПИАЛЬНО разные функции, и объединять их под общим именем не вижу никакого смысла, кроме чисто программистских заморочек, которых всегда старался избегать.

Если имя ф-ции как заноза в глазу, назови её CallSpecialFunction() и тогда

Джон совершенно правильно намекает на такой шаблон проектирования, как Command.

Джон, ezus правильно говорит, нельзя так делать, если следовать твоему предложению, то:
1. Это уже не наследование по логике (наследуемые классы наследуют поведение предка, а тут сразу нарушение этого правила)

Здесь нет наследования, здесь обобщение - просто желание ослабить типизацию, чтобы впихнуть разное в общий массив. По твоей логике абстрактные методы (или "pure virtual", как их в C++ называют) бесполезны, ибо от них нечего наследовать. Издержки языка со статической типизацией, к коим относится C++.

2. Так можно решить только частную задачу, ну например, у меня таких массивов 100 штук и в каждом из них должна быть разная обработка объектов в зависимости от типа, чтож мне миллион функций в эти классы впихать, чтоб при любой обработке вызвать одну, но виртуальную?

Для этого человечество изобрело такие шаблоны, как Command, Strategy и Bridge

преобразование родительского типа к конкретному. Любое такое преобразование - проявление анти ООП настроений. Указывет исключительно на слабо продуманную архитектуру.

Как говорится, +1

warning C4541: 'dynamic_cast' used on polymorphic type 'class Keta' with /GR-; unpredictable behavior may result

В настройках проекта убери ключ /GR-.

[lapulya]

Dimka,

По твоей логике абстрактные методы (или "pure virtual", как их в C++ называют) бесполезны, ибо от них нечего наследовать.

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

Для этого человечество изобрело такие шаблоны, как Command, Strategy и Bridge

да кто спорит? Я лишь сказал, что плодить (именно плодить) подобные предложенной Джоном функции - не вариант, они спасают лишь от очень узкой проблемы (обработка конкретного списка в конкретном месте)

Понимаю, что все останутся при своих, но:
пример с врачами мог бы быть не совсем таким простым (хотя вариант с юнитами нагляднее дискредитирует предложенный Джоном вариант). Предположим, для женщин есть 2 уникальных врача (гинеколог1 и гинеколог2), и у мужчин тоже 2 уникальных (ну там... логопед1 и логопед2). Для каждого врача (это абстракция, т.е. чисто для примера) у классов М и Ж есть своя функция (если они одинаковые, то она еще есть и в базовом как виртуальная). Естественно, что разные врачи (гинеколог1, гинеколог2, логопед1 и логопед2 это разные врачи) лечат разные болезни с разными симптомами, а вот педиатор и М и Ж лечит одинаково и симтомы болезни одинаковы.  При этом имеется общий список, в котором и мужчины и женщины. Надо в конкретном обработчике списка (а список может быть не один + обработчиков, что более реалистично, так же не один) исходя из каких-то внешних данных (ввод руками или берем из карты) вызвать у объекта списка нужную функцию (или не вызывать ничего, женские болезни имеют по отношению с мужчинами уникальные симтомы). Представь, что будет если задача будет решаться введением в базовый класс общих методов (и главное сколько их там надо добавить!!!) : f1 (для гинеколог1 для женщин, а для мужчин она будет пустая) и т.д. еще 3 функции (одна для Ж и 2 для М)... ИМХО - утопия. Рабочий вариант - разные списки для М и Ж или каст... да, да если сигнатура функций одинакова, можно обойтись малой кровью (шаблонами), а если нет... при данной архитектуре ппц.

[Dimka]

Пусть есть исходные классы (не обсуждаем, какие и зачем они такие).

Код: (C++)

class Keta
{
public:
    virtual void locate() = 0;
    virtual ~Keta() {}
};

class Pattern:
    public Keta
{
public:
    void locate()
    {
        cout << "Pattern.locate" << endl;
    }
    void fp()
    {
        cout << "Pattern.fp" << endl;
    }
};

class Shape:
    public Keta
{
public:
    void locate()
    {
        cout << "Shape.locate" << endl;
    }
    void fs()
    {
        cout << "Shape.fs" << endl;
    }
};

Ставится задача упаковать их в массив и, обходя этот массив, выполнять специфические для каждого элемента действия. Для этого служит шаблон Command.

Кроме того, хочется извлекать из массива хранимые там элементы. Для этого служит шаблон Variant.

Их соединение приводит к решению:

Код: (C++)

class Command
{
public:
    virtual void run() = 0;
    virtual ~Command() {};
};

template<class Item>
class ArrayItem:
    public Command
{
protected:
    Item *item;
public:
    ArrayItem(Item *item):
        item(item)
    {}
    Item *getItem() const
    {
        return this->item;
    }
};

class ArrayItemPattern:
    public ArrayItem<Pattern>
{
public:
    ArrayItemPattern(Pattern *pattern):
        ArrayItem<Pattern>(pattern)
    {}
    void run()
    {
        this->getItem()->fp();
    }
};

class ArrayItemShape:
    public ArrayItem<Shape>
{
public:
    ArrayItemShape(Shape *shape):
        ArrayItem<Shape>(shape)
    {}
    void run()
    {
        this->getItem()->fs();
    }
};

Эта обёрточного типа надстройка никак не покушается на исходные классы и достаточно автономна от них. В принципе она представляет собой вырожденный случай шаблона Bridge, создающего альтернативное, построенное на других принципах дерево тех же самых элементов, образующих две иерархии сразу.

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

Код: (C++)

class Array
{
private:
    typedef vector<Command *> _Array;
    _Array array;
public:
    void add(Pattern *pattern)
    {
        this->array.push_back(new ArrayItemPattern(pattern));
    }
    void add(Shape *shape)
    {
        this->array.push_back(new ArrayItemShape(shape));
    }
    int getSize() const
    {
        return this->array.size();
    }
    template<class Type>
    Type *getItemAt(int i)
    {
        if(i < 0 || i >= this->getSize())
        {
            return NULL;
        }
        Type *container = dynamic_cast<Type *>(this->array[i]);
        typedef ArrayItem<Type> Item;
        Item *item = dynamic_cast<Item *>(this->array[i]);
        return item ? item->getItem() : container;
    }
    ~Array()
    {
        for(int i = 0; i < this->getSize(); ++i)
        {
            delete this->array[i];
        }
    }
};

И написать код, который использует всё это решение.

Код:

    Array array;
    array.add(new Pattern());
    array.add(new Shape());
    for(int i = 0; i < array.getSize(); ++i)
    {
	// Test 1
	Pattern *pattern = array.getItemAt<Pattern>(i);
	cout << i << " is " << (pattern ? "" : "not ") <<  "Pattern" << endl;
	// Test 2
	Shape *shape = array.getItemAt<Shape>(i);
	cout << i << " is " << (shape ? "" : "not ") <<  "Shape" << endl;
    }
    // Test 3
    for(int i = 0; i < array.getSize(); ++i)
    {
	array.getItemAt<Command>(i)->run();
    }
    // Warning: Not free memory.

на выходе получаем

Код:

0 is Pattern
0 is not Shape
1 is not Pattern
1 is Shape
Pattern.fp
Shape.fs

[Dimka]

пример с врачами мог бы быть не совсем таким простым (хотя вариант с юнитами нагляднее дискредитирует предложенный Джоном вариант). Предположим, для женщин есть 2 уникальных врача (гинеколог1 и гинеколог2), и у мужчин тоже 2 уникальных (ну там... логопед1 и логопед2). Для каждого врача (это абстракция, т.е. чисто для примера) у классов М и Ж есть своя функция (если они одинаковые, то она еще есть и в базовом как виртуальная).

О, для случая хождения по врачам человечество изобрело шаблон Visitor

[lapulya]

дык, я ж об этом и написал, что в самих Pattern, Shape и Keta ничего добавлять не надо. Наоборот, все, что связано с обработкой должно быть венесено (исходные классы достаточны в своем интерфейсе). А вот предложенное димкой решение и есть архитектурное решение проблемы (оно общее, т.к. не затрагивает самих Pattern, Shape и Keta). Тут я полностью согласен с Димкой.

Визитор из той же бочки.

Тут нет (и не будет такого), что функция расчета ведомости печатает расписание поездов.

[Антон (LogRus)]

и в чём проблема?

Код:

class IHuman
{
public:
    virtual ~IHuman() = 0;
    
    virtual void GoToDoctor() = 0;
    virtual void DoSomeThingVerySpecialOnEachOperation() = 0;
};

class TAdult : public IHuman
{
public:
    ~TAdult(){;}
    virtual void GoToDoctor()
    {
        GoToDoctor1();
        GoToDoctor2();
        GoToDoctor3();
    }
private:
    void GoToDoctor1();
    void GoToDoctor2();
    void GoToDoctor3();    
};


class TAdultMan : public TAdult
{
public:
    TAdultMan(){;}
    virtual void GoToDoctor()
    {
        Adult::GoToDoctor();
        GoToDoctor3();
    }
private:
    void GoToDoctor3();    
};

class TAdultWoman : public TAdult
{
public:
    TAdultWoman(){;}
    virtual void GoToDoctor()
    {
        Adult::GoToDoctor();
        GoToDoctor4();
    }
private:
    void GoToDoctor4();    
};

typedef std::vector<IHuman> TPatients;
typedef TPatients::iterator TPatientsIter;

void ProcessAll(TPatients & data)
{
    for (TPatientsIter it = data.begin(); it != data.end(); ++it)
    {
        it->GoToDoctor();
        it->DoSomeThingVerySpecialOnEachOperation();
    }
}

[Джон]

Я лишь сказал, что плодить (именно плодить) подобные предложенной Джоном функции - не вариант, они спасают лишь от очень узкой проблемы (обработка конкретного списка в конкретном месте)

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

Понимаю, что все останутся при своих

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

ps ИМХО получился небольшой флуд с отклонением от основной темы, в котором вопросы ezus-а легко теряются. Стоит ли его выделить в отдельную тему? Тема-то, похоже, вечная. Есть смысл её продолжать?

[ezus]

Стоит ли его выделить в отдельную тему? Тема-то, похоже, вечная. Есть смысл её продолжать?

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

Всем СПАСИБО.
Я получил исчерпывающие ответы на все мои вопросы.

P.S. По поводу "ВЫ\ТЫ".
Это просто мое древнее воспитание, с которым я борюсь. Поэтому мое "ВЫ" ни к сарказму, ни к неувожению отношения не имеет. Обещаю в следующий раз постараться сразу начинать с "ТЫ".

[Джон]

Да, не, я и не подумал про сарказм и пр. Да и воспитание штука хорошая. Просто с друзьями как-то всё больше на "ты".

[lapulya]

Антон (LogRus),
))))))) бугага... ты меня не понял... когда у человека что-то болит его не посылают ко всем врачам сразу, а посылают к конкретному, суть вот в чем (причем Димка описал концепцию  решения).

Код:

class Human
{
  ...
  virtual void GoToDoctor1() = 0; // тут можно убрать чисто вирт. и написать реализацию... не суть.
  virtual void GoToDoctor2() = 0; // тут можно убрать чисто вирт. и написать реализацию... не суть.
  virtual void GoToDoctor3() = 0; // тут можно убрать чисто вирт. и написать реализацию... не суть.
}

class Man : public Human
{
  ...
  void GoTo_MAN_Doctor1() {}
  void GoTo_MAN_Doctor2() {}
}

class Woman : public Human
{
  ...
  void GoTo_WOMAN_Doctor1() {}
  void GoTo_WOMAN_Doctor2() {}
}

typedef std::vector<IHuman> TPatients;
typedef TPatients::iterator TPatientsIter;

void ProcessAll(TPatients & data, Симптом & симптом)
{
    for (TPatientsIter it = data.begin(); it != data.end(); ++it)
    {
        if (симптом == 1)
            it->GoToDoctor1();  // это вирт. функция предка по общему врачу для М и Ж по одинаковым симптомам
        else if (симптом == 2)
            it->GoToDoctor2();  // это вирт. функция предка по общему врачу для М и Ж по одинаковым симптомам
        else if (симптом == 3)
            it->GoToDoctor3();  // это вирт. функция предка по общему врачу для М и Ж по одинаковым симптомам

        else if (симптом == ЧИСТА_КАНКРЕТНА_ЖЕНСКИЙ_СИМПТОМ1)
            ??????????;
        else if (симптом == ЧИСТА_КАНКРЕТНА_ЖЕНСКИЙ_СИМПТОМ2)
            ??????????;
        else if (симптом == ЧИСТА_КАНКРЕТНА_МУЖСКОЙ_СИМПТОМ1)
            ??????????;
        else if (симптом == ЧИСТА_КАНКРЕТНА_МУЖСКОЙ_СИМПТОМ2)
            ??????????;
    }
}

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

Нееее надо будет именно плодить, ибо одной функции будет мало

[Dimka]

Далась вам эта архитектура . Вопрос к C++ отношения не имеет.

В отечественных поликлиниках до сих пор есть такое явление, как "участковый терапевт", а местами для людей состоятельных - "личный лечащий врач". Именно он решает, к каким специалистам и с какой целью направлять пациента, а также когда выдавать больничный, выписывать и т.д.

Решения о конкретном специалисте терапевт принимает, основываясь на симптомах, поле и возрасте пациента.

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

Каждый врач может определить, к нему данный пациент или нет.

Получается такое решение:

Код: (Ruby)

# Пациент
class Patient
 
  # Пол
  Male = 0
  Female = 1
 
  def initialize(name, birth_year, sex)
    @name = name
    @birth_year = birth_year
    @sex = sex
    @doctors_list = Array.new
  end
 
  attr_reader :name, :sex

  def age
    # Примерный возраст
    return Time.now.year - @birth_year
  end

  # Получает направление к врачу
  def assign(doctor)
    puts "#{self.name} получил направление к #{doctor.name}"
    if not @doctors_list.include? doctor then
      @doctors_list.push doctor
    end
  end

  # Проходит курс лечения
  def medical_treatment
    while not @doctors_list.empty?
      doctor = @doctors_list.shift
      doctor.receive self
    end
  end

end

# Абстрактный врач
class Doctor

  attr_reader :name

  def receive(patient)
    # Приём пациента
    puts "#{self.name} принял #{patient.name}"
  end

  def accept?(patient)
    # Принимает любых пациентов
    return true
  end

end

class Physician < Doctor

  def initialize(specialists)
    @name = "Терапевт"
    @specialists = specialists
  end

  def receive(patient)
    super patient
    # Назначает всех подходящих специалистов
    for specialist in @specialists
      if specialist.accept? patient then
        patient.assign specialist
      end
    end
  end

end

class Pediatrician < Doctor

  def initialize
    @name = "Педиатр"
  end

  def accept?(patient)
    # Принимает пациентов до 14 лет
    return patient.age < 14
  end

end

class Surgeon < Doctor

  def initialize
    @name = "Хирург"
  end

end

class Gynaecologist < Doctor

  def initialize
    @name = "Гинеколог"
  end

  # Принимает женщин
  def accept?(patient)
    return patient.sex == Patient::Female
  end

end

patients =
  [
    Patient.new("Ваня", 2003, Patient::Male) ,
    Patient.new("Василий Петрович", 1938, Patient::Male) ,
    Patient.new("Елена", 1992, Patient::Female)
  ]

specialists =
  [
    Pediatrician.new,
    Surgeon.new,
    Gynaecologist.new
  ]

physician = Physician.new specialists

for patient in patients
  physician.receive patient
end

for patient in patients
  patient.medical_treatment
end

Результаты работы:

Код:

Терапевт принял Ваня
Ваня получил направление к Педиатр
Ваня получил направление к Хирург
Терапевт принял Василий Петрович
Василий Петрович получил направление к Хирург
Терапевт принял Елена
Елена получил направление к Хирург
Елена получил направление к Гинеколог
Педиатр принял Ваня
Хирург принял Ваня
Хирург принял Василий Петрович
Хирург принял Елена
Гинеколог принял Елена

Как-то так...

[Антон (LogRus)]

Антон (LogRus),
))))))) бугага...

всё это чушь и отношения к делу не имеет, можно сколь угодно строить теории и прочее, но они хороши в конкретном практическом приложении, а это приложение есть у автора темы


Dimka, если мы решаем проблему докторов и пациентов, то твое решение мне больше нравится, но бывают и другие задачи

похоже тема действительно себя исчерпала

[Джон]

похоже тема действительно себя исчерпала

Ага, ещё в зародыше.