С++, интерфейсы

Realist

class SimpleWeather

{

public:

virtual int getTemperature;

};



class RainyWeather : public SimpleWeather

{

public:

virtual double getRainIntensity; // Новый метод, нету в предке!

}



simpleWeather * getCurrentWeather;

krishtaf

Dasar

Пробовать делать dynamic_cast на результат?

Realist

klyv

ppplva

Serab

krishtaf

Проблема в том, что у меня есть функция, которая может вернуть как базовый класс, так и потомка. У потомка могут быть методы, которых нет у предка или других потомков. Как мне до того метода добраться?

SPARTAK3959

abstract class Lookup

{

public:

  virtual void* getObject(char* type);//или std::string type

}

abstract class SimpleWeather:Lookup

{

public:

  virtual int getTemperature;

}

abstract class RainyInfo

{

public:

  virtual double getRainIntensity;

}

class RainyWeather:SimpleWeather,RainyInfo

{

public:

  //тут за правильность синтаксиса не ручаюсь.

  override double getRainIntensity{return 0;}

  override void* getObject(char* type){

//здесь можно использовать map.

//можно разрешить добавлять/удалять возможности динамически, подгружать их из плагинов-dll'ек имена которых находятся в каком-нибудь xml-нике и.т.д.

  if (strcmp(type,"RainyInfo")==0)

  {

    return &(RainyInfo)this;

  }

  return NULL;

  }

}

karkar

Еще есть Netbeans way:

kokoc88

Как мне правильно реализовать и использовать библиотеку? Пробовать делать dynamic_cast на результат? Добавить метод getType? Добавить в предка simpleWeather заглушку для getRainIntensity?

Serab

dynamic_cast, и метод getType. В общем-то они эквивалентны с точки зрения проектирования.

Serab

kokoc88

Ну что значит эквивалентны? Нет. Если у тебя есть getType, то ты пользователю сразу раскрываешь полную информацию о себе, если же делать только dynamic_cast, то клиент может только проверить, поддерживает ли данный объект некоторый интерфейс. Это более безопасно.

kokoc88

Но если некоторые типы погоды действительно должны быть как-то по особому _реализованы_, то может пригодиться паттерн State.

Serab

Под функцией getType понималась не GetType из C#, а обычная функция, которая возвращает какой-нибудь enum. И если этот enum равен rainy_weather, то ты можешь смело приводить указатель к нужному тебе типу. Это несколько проще, чем делать несколько dynamic_cast в поисках конкретики. С точки зрения проектирования эти решения эквивалентны.

Serab

Ни одно из применений этого паттерна не подходит к поставленной задаче.

Maurog

class SimpleWeather

{

public:

  virtual ~SimpleWeather {}

  virtual int getTemperature const = 0;

  virtual double getRainIntensity const = 0;

};



std::auto_ptr<SimpleWeather> getCurrentWeather;

class SimpleWeather

{

public:

  virtual ~SimpleWeather {}

  virtual int getTemperature const = 0;

};



class RainyWeather

{

public:

  virtual ~RainyWeather {}

  virtual double getRainIntensity const = 0;

};



std::auto_ptr<SimpleWeather> getCurrentWeather;

std::auto_ptr<RainyWeather> getCurrentRainyWeather;

rosali

kokoc88

Это пример грубейшей ошибки проектирования: ты дублируешь иерархию в еще каком-то enum'е, это приведет к апокалипсису: ты создаешь еще один производный класс, но у тебя нет доступа к определению enum'а: что ты будешь возвращать в соответствующем методе?

kokoc88

Конечно же подходит. Ты где прочитал, что не подходит? Я применял этот паттерн в сходной ситуации и все были довольны.

kokoc88

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

Ivan8209

Dasar

как проблему конктеризации абстракции, и уже привёл одно иp решений из книжки - это паттерн Visitor.

kokoc88

пример приведи, пожалуйста.

Dasar

Если тебе требуется код, то он есть в Wikipedia. Впрочем, там описан Hierarchical Visitor, а ты почему-то не признаёшь реализацию с иерархией классов без коллекций. (Кстати там пример не очень удачный с той точки зрения, что обход коллекции следовало бы реализовать внутри элемента.)
Если тебе требуется ссылка, откуда взялось моё утверждение, то могу привести цитату из GoF: "an object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes".

kokoc88

вот допустим есть абстракция "список": даже есть его кокретизации: IEnumerable<T>, ICollection<T>, IList<T>, T[], List<T> и т.д. а визитер здесь как применим?

Dasar

kokoc88

какое отношение - это все имеет - к "конкретизации абстракции"?

Может, в веб-приложении отрисовываться будет, может всплытием подводной лодки командовать.

Dasar

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

kokoc88

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

rosali

#include <memory>

#include <iostream>

using namespace std;



class Visitor;



struct Expr {

    virtual void Accept(Visitor & v) = 0;

};



struct Const; struct Add; struct Negate;



class Visitor {

public:

    virtual void visit(Const & e) = 0;

    virtual void visit(Add & e) = 0;

    virtual void visit(Negate & e) = 0;

    void Visit(Expr & e) { e.Accept(*this); }

};



struct Const: public Expr {

    int c;

    Const(int c): c(c){}

    virtual void Accept(Visitor & v) { v.visit(*this); }

};



struct Add: public Expr {

    auto_ptr<Expr> x;

    auto_ptr<Expr> y;

    Add(Expr * x, Expr * y): x(x y(y) {}

    virtual void Accept(Visitor & v) { v.visit(*this); }



};



struct Negate: public Expr {

    auto_ptr<Expr> x;

    Negate(Expr * x): x(x) {}

    virtual void Accept(Visitor & v) { v.visit(*this); }

};





class Show: public Visitor {

public:

    virtual void visit(Const & e) {

        cout << e.c;

    }

    virtual void visit(Add & e) {

        cout << "(";

        Visit(*e.x);

        cout << ")+(";

        Visit(*e.y);

        cout << ")";

    }

    virtual void visit(Negate & e) {

        cout << "-(";

        Visit(*e.x);

        cout << ")";

    }

};



class Eval: public Visitor {

public:

    int state;

    virtual void visit(Const & e) {

        state = e.c;

    }

    virtual void visit(Add & e) {

        Visit(*e.x);

        int x = state;

        Visit(*e.y);

        int y = state;

        state = x+y;

    }

    virtual void visit(Negate & e) {

        Visit(*e.x);

        state = -state;

    }

};





int main  {

    auto_ptr<Expr> e(new Add(new Negate(new Add(new Const(2 new Negate(new Const(1 new Const(3;

    Show.Visit(*e);

    cout << endl;



    Eval i;

    i.Visit(*e);

    cout << i.state << endl;

    return 0;

}

[xoft ~]$ ./visitor

(-2)+(-(1+(3)

2

Dasar

Ты про проблему с double dispatch?

using (var weatherStation = new WeatherStation

{

   var weather = weatherStation.GetCurrentWeather;



   weather.If<RainWeather>(rainWeather =>

    {

       Console.WriteLine("Rain: {0}", rainWeather.RainIntesitiy);

    });

}

void OnLoad

{

   this.weatherStation = new WeatherStation;

}

void OnStart

{

   this.weather = weatherStation.GetCurrentWeather;

}

void OnShow

{

   weather.If<RainWeather>(rainWeather =>

    {

       Console.WriteLine("Rain: {0}", rainWeather.RainIntesitiy);

    });

    

}

void OnDispose

{

  weatherStation.Dispose;

}

Dasar

никакого спагетти

kokoc88

вот это прямой поток управления (все принятия решений идут последовательно, в одном месте, понятно как делается прерывание или изменение потока управления)

Dasar

Тогдя я не понял, какое всё это имеет отношение к Visitor. У нас есть N абстракций и растущее число операций, которые требуют конкретизации. (Собственно это и написано в цитате из GoF.)

if (weather is RainWeather)

{

  ...

}

void OnRainWeather

{

}

kokoc88

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

kokoc88

тем, что ты предлагаешь

Dasar

Приведённый тобою код не показывает ошибочности картины применения серий if/else. Как только ты начнёшь наращивать количество операций, сразу же увеличится циклическая сложность кода.

SwitchOnType(weather)

.Case<RainWeather>(rainWeather => 

   {

     textBox.Text = "rain"; rainTextBox.Text = rainWeather.RainIntensity.ToString;

   })

.Case<SunWeather>(sunWeather => {image.Image = Images.Sun;})

//и т.д.

new MyVisitor(textBox, rainTextBox, rainTextBox, image, Images).Visit(weather);





class MyVisitor: IWeatherVisitor

{

   public void OnRainWeather(RainWeather rainWeather)

   {

     textBox.Text = "rain"; rainTextBox.Text = rainWeather.RainIntensity.ToString;

  }

  public void OnSunWeather(SunWeather sunWeather)

  {

    image.Image = Images.Sun;

  }

}

kokoc88

SwitchOnType(weather)
.Case<RainWeather>(rainWeather =>
{
textBox.Text = "rain"; rainTextBox.Text = rainWeather.RainIntensity.ToString;
})
.Case<SunWeather>(sunWeather => {image.Image = Images.Sun;})

Dasar

class Eval: public Visitor {
public

Dasar

Это по-твоему не увеличение циклической сложности?

Как на это написать unit test для каждой операции?

Как внести в этот код состояния?

karkar

циклическая сложность кода

kokoc88

А что это? Или имелась в виду цикломатическая ?

rosali

kokoc88

циклическая сложность между чем и чем?

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

состояние уже есть, в виде textBox, rainTextBox и т.д.
с визитором - это состояние пришлось явно передавать через конструктор

Dasar

Очевидно, что в switch решениях она выше, чем в double dispatch

Dasar

Просто циклическая сложность функции с операцией.

Показатель цикломатической сложности является одним из наиболее распространенных показателей оценки сложности программных проектов. Данный показатель был разработан ученым Мак-Кейбом в 1976 г., относится к группе показателей оценки сложности потока управления программой и вычисляется на основе графа управляющей логики программы (control flow graph). Данный граф строится в виде ориентированного графа, в котором вычислительные операторы или выражения представляются в виде узлов, а передача управления между узлами – в виде дуг.

«Упрощенное» вычисление цикломатической сложности – предусматривает вычисление не на основе графа, а на основе подсчета управляющих операторов.

kokoc88

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

kokoc88

кстати ты подменяешь реальную цикломатическую сложность формальной("упрощенной").

Dasar

Ну если тебе это не очевидно, то тебе следует прочитать что-нибудь про unit testing.

В своём посте я сравнивал сложность тестирования одной операции, а не каждой.

Dasar

на все случаи жизни возвращаемых типов не напасешься

Dasar

Но с точки зрения языка, в котором реализован multiple dipatch сложность будет равна 1.

Dasar

Это сделано намеренно.

Dasar

kokoc88

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

на самом деле цикломатическая сложность у них одиннаковая и для тестирования обоих решений нужно одиннаковое кол-во тестов: по кол-ву погод.

kokoc88

пример такого решения можно, на котором будет наглядно показано, что вместо идеального кол-ва тестов m*n достаточно лишь m+n тестов.

Dasar

Ты и сам можешь нагуглить реализацию Visitor на CLOS или F#/Ocaml.

kokoc88

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

Dasar

Что такое полное покрытие unit test-ом ты знаешь?

Почему в твоём случае каждый Case имеет сложность равную 2 представляешь?

Почему для полного покрытия такого проэмулированного switch-а надо написать более сложный unit test, чем при использовании встроенного в язык программирования switch понимаешь?

var result = items.Select(item => item.ToString.ToArray;

var list = new List<string>

foreach (var item in items)

  list.Add(item.ToString;

var result = list.ToArray;

Очень интересно, а как выглядит функция Case<T> ?

 И что будет, если какой-нибудь нерадивый разработчик её неправильно подправит под свои нужды?

А что делать, если перед конкретизацией абстракции нужно её уточнение, или если это уточнение понадобится в будущем?

Serab

Это не пример грубейшей ошибки проектирования, а пример решения задачи. Иерархии в enum-е не будет, там будут перечислены все подтипы. Для расширяемости можно возвращать строку или guid, но опять же, с точки зрения проектирования это параллельно. Здесь незачем вдаваться в технические детали реализации, а то придётся дойти до момента, что фабрика классов, создающая конкретные типы, тоже должна быть расширяемой извне. (И продолжить тем, что в правильных языках это сделать в порядки проще, чем в C++/C#/Java.)
В общем-то описанная проблема с enum будет возникать в том или ином виде и в Visitor. Ровно как и при полном дублировании всех интерфейсов с заглушечными реализациями - добавление нового конкретного класса может привести к требованию добавить новую функцию в самый главный интерфейс.

kokoc88

нет, не представляю.
особенно если учесть что эта некая библиотечная вещь.

сдохнут тесты библиотеки.

Dasar

Мы рассматриваем реализацию конкретизации абстракции, а не тела операций.

Switch(...)

.Case<TType1>(..)

.Case<TType2>(...)

Dasar

Какая разница, библиотечная вещь или нет? Её циклическая сложность равна двум - либо делегат выполнится, либо не выполнится. Очевидно, это усложняет как тестирование, так и анализ кода.
сдохнут тесты библиотеки.

А что, если он её напишет так, что не сдохнут?

Dasar

А что, если он её напишет так, что не сдохнут?

kokoc88

Вот тут ты неясно зачем апеллировал к Visitor и заглушечным реализациям, которых я не предлагал.

Ты говоришь решения через getType и dynamic_cast эквивалентны

Dasar

Нет. Я говорю, что с точки зрения ООП они эквивалентны.

Serab

Ты предложил паттерн State, который не решает поставленную задачу.

Нет. Я говорю, что с точки зрения ООП они эквивалентны.

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

kokoc88

в моем решении надо один раз на всю жизнь протестировать правильность реализации конструкции

в решении с визиторами, надо каждый раз тестировать эти самые визиторы:
WeatherVisitor для иерархии погод,
WheelVisitor для иерархии колес,
PeopleVisitor для иерархии людей
и т.д.

kokoc88

На момент написания тобой цитируемого мной сообщения про State я еще не говорил.

Serab

Тогда извини, но я потерял ход твоих рассуждений.
Скажи ещё раз, как ты видишь применение паттерна State.

И повторись, в чём с точки зрения ООП (а не конкретного языка программирования) различаются серии dynamic_cast и switch конструкция.

Serab

kokoc88

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

kokoc88

хотя предложил ты откровенную глупость с этим enum'ом

Dasar

Нет, надо тестировать только методы этих классов. Double dispatch тебе обеспечивает компилятор.

Serab

Да? А ты посчитай ту же сложность реализации операций с dynamic_cast и с enum и увидишь, что у обоих подходов есть как плюсы, так и минусы.

kokoc88

я правильно тебя понял, что ты считаешь, что, например, в решении не надо проверять, что функция Accept каждого класса Const, Add, Net вызывает соответствующую функцию из класса Visitor?

kokoc88

Дело не в сложности реализации, а в том, что enum - небезопасно, тяжело расширяется и несколько мешает инкапсуляции.

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

Serab

Я не могу увидеть твоих аргументов с точки зрения ООП. По-твоему без Си++ оно не существует?

Чем enum небезопасен с точки зрения ООП? Как он мешает инкапсуляции?

Я и не могу понять, почему?

kokoc88

Что, оно, извини?

Небезопасен и мешает инкапсуляции он потому, что раскрывает клиенту полностью информацию о динамическом типе. Опять же, почему в COM сделано QueryInterface, но нету чего-нибудь типа GetCLSID?

Dasar

Эмуляцию через switch конструкцию надо протестировать для каждой операции.

  class Switch

  {

    interface ICase 

    {

      bool Execute(object item);

    }



    class SwitchCase<T>:ICase

    {

      public SwitchCase(Action<T> action)

      {

        this.action = action;

      }

      Action<T> action;

      public bool Execute(object item)

      {

        if (!(item is T

          return false;

        actionT)item);

        return true;

      }

    }

    public Switch Case<T>(Action<T> action)

    {

      cases.Add(new SwitchCase<T>(action;

      return this;

    }

    List<ICase> cases = new List<ICase>

    public void Execute(object item)

    {

      foreach (var @case in cases)

      {

        if (@case.Execute(item

          break;

      }

    }

  }



  class Program

  {

    static void Main(string[] args)

    {

      string result = null;



      var @switch = 

        new Switch

         .Case<int>(i => {result = "int";})

         .Case<Form>(i => { result = "Form"; })

         .Case<Control>(i => { result = "Control"; })

         .Case<object>(i => { result = "object"; })

         ;



      var tests = new[]

        {

          new { Value = (object)1, Etalon = "int"},

          new { Value = (object)new Form Etalon = "Form"},

          new { Value = (object)new Control Etalon = "Control"},

          new { Value = (object)new object Etalon = "object"},

        };



      foreach (var test in tests)

      {

        result = null;

        @switch.Execute(test.Value);

        if (result != test.Etalon)

          Console.WriteLine("Тест для типа '{0}' не прошел. Ожидалось '{1}', а получили '{2}'",

             test.Value.GetType.FullName, test.Etalon, result);

      }

 }

}

kokoc88

какое-нибудь обоснование все-таки будет для этого утверждения?

                if (!typeof(T).IsAssignableFrom(item.GetType

                    return false;

                if (typeof(T) != item.GetType

                    return false;  

Dasar

Уже потенциальная ошибка, которая может проявиться только в какой-то отдельно взятой switch конструкции.

kokoc88

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

Dasar

Очевидно, что операция может быть вызвана для типа, к которому её нельзя применять. Или не вызвана для типа, к которому её нужно было применить.

kokoc88

чего? как это?

Dasar

Просто, в иерархии эти типы могут состоять в отношении наследования.

Serab

А какую мы решаем задачу? Пока что я считал, что мы конкретизиурем абстрактный класс. Сколько есть типов, которые надо конкретизировать, столько значений у enum, и столько же типов будет использоваться в большом if/else при использовании dynamic_cast.

Кроме того, COM не основан на серии dynamic_cast. Поэтому мне слабо понятно, куда ты клонишь.

kokoc88

это покроется тестами, что наш код правильно отрабатывает все варианты погоды.

Serab

И я не клоню, а утверждаю, что функциональность, которую ты хочешь _продублировать_ enum'ом уже есть в обсуждаемом языке программирования и твое решение _по этой причине_ отстой

Dasar

То есть даже в том случае, когда тестировать какой-либо конкретный тип погоды не нужно, тебе всё равно придётся написать отдельный unit test на этот случай.

И ещё одна проблема возникнет, когда в одном случае потребуется одинаковый метод для разных типов, а в другом - разный код для этих же типов.

Тогда ещё придётся следить за тем, что Case для базовых типов стоит перед Case для производных.

Я думаю, что привёл достаточно недостатков. И с этими недостатками я не увидел ни одного преимущества перед классической реализацией Visitor через double dispatch.

Ivan8209

Serab

Я правильно понимаю, что от исходного вопроса "как моделировать,"
все перешли к обсуждению частных проблем ООП?

kokoc88

Количество подтипов может изменяться в будущем, при этом очень легко забыть не расширить соответствующий enum, неужели непонятно?

Как это не основан? Там QueryInterface — прямой аналог dynamic_cast.

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

Serab

И этих минусов, кстати, даже меньше, чем в решении с dynamic_cast

Ivan8209

Serab

Для этого сначала надо "легко забыть" не расширить не одну операцию для этого нового типа.

kokoc88

наглядность и атомарность выше
double dispatch - только скорость обеспечивает, но никак не уменьшение тестов, или улучшение читабельности.

kokoc88

Так ты ни одного еще не привел минуса dynamic_cast

Serab

именно для того, чтобы повысить безопасность и расширяемость в COM перешли от dynamic_cast к решению, основанному на GUID-ах.

Dasar

Почему это наглядность выше, если увеличилась циклическая сложность и добавилась какая-то дополнительная generic библиотека со сложным поведением?
Почему выше атомарность, если увеличена связность (coupling) и происходит дублирование кода?

Serab

Так ты сам тут писал про COM и QueryInterface. Ты перед этим не прочитал, зачем это было сделано? Как раз чтобы исправить минусы dynamic_cast.

Serab

исправить минусы dynamic_cast.

kokoc88

Я от тебя прошу: список минусов dynamic_cast по отношению к getType в контексте вопроса топикстартера.

kokoc88

Поэтому утверждение, что они там перешли от чего-то к dynamic_cast абсурдно.

Serab

Два разных компилятора.

Более высокий class coupling.

Более высокая алгоритмическая сложность (код будет намного медленнее работать).

Придётся писать dynamic_cast для потомков перед dynamic_cast для родителей, а это дополнительные ошибки в программе.

kokoc88

О чем вы?

Не вижу почему с getType он «более низкий»

Serab

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

kokoc88

обоснуй, пожалуйста. все три утверждения не наблюдаю.

Почему это наглядность выше, если увеличилась циклическая сложность и добавилась какая-то дополнительная generic библиотека со сложным поведением?

Почему выше атомарность, если увеличена связность (coupling) и происходит дублирование кода?

kokoc88

Ну так когда ты связываешься с определенным типов, как раз у тебя этот самый coupling и увеличивается!

Serab

С каким типом я связываюсь?
if (dynamic_cast<C1*>(pc
independant_of_c1_method;
else if (dynamic_cast<C2*>(pc
independant_of_c2_method;
else if (dynamic_cast<C3*>(pc
independant_of_c3_method;
switch (enum) + 3 case/break + все три метода.

kokoc88

Ну вот, я добавляю еще один тип в иерархию. Первый метод работает корректно: с доступным интерфейсом (если скастилось, то хорошо). Твой же код не ясно как будет работать.

Serab

Точно так же!

kokoc88

Ага, т.е. ты предлагаешь у вновь созданного класса в качестве getType возвращать тот же результат, что и у предка? Или как иначе это можно реализовать?

Serab

Нет, я предлагаю возвращать новый.

Serab

Ещё раз повторюсь, моё утверждение было в том, что dynamic_cast и enum одинаковы с точки зрения ООП.

Dasar

Ещё раз повторюсь, моё утверждение было в том, что dynamic_cast и enum одинаковы с точки зрения ООП.

interface IA{}

interface IB:IA 

{

    int X {get;}

}

interface IC:IA 

{

    int Z {get;}

}



void Main

{



IA a = GetCurrentA;



if (a is IB)

  Console.WriteLineIB)a).X);



if (a is IС)

  Console.WriteLineIС)a).Z);

}

kokoc88

А как тогда твой switch без изменений отработает? Там тогда будет попадание в ветку default и что? Через самый базовый класс полезет.

kokoc88

если они эквивалентны, то как через enum реализуется следующий код?

Serab

QueryInterface в COM не основан на серии dynamic_cast. Он сам по себе является семантическим аналогом dynamic_cast

kokoc88

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

Serab

Когда оно попадёт в default то сделает тоже самое, что и серия твоих dynamic_cast в последнем else.

struct A {};

struct B : A {};

struct C : B {};



...

A *p = new C;



dynamic_cast< B* >( p ) == ?

Serab

Потому что ООП не ограничивается языком Си++, а для меня технические проблемы того или иного языка не являются проблемами ООП.

kokoc88

Не является он _семантическим_ аналогом dynamic_cast, потому что может вообще создавать новые объекты, делать много других ужасных вещей. Ну что ты несешь?

Serab

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

Serab

Приведи пример QueryInterface, который создаёт новые объекты.

kokoc88

Выходит ты не знаешь как работает dynamic_cast. Давай проверим.

kokoc88

Какого рода тебе пример нужен? Я сейчас спокойно напишу компонент, у которого есть довольно редко используемый интерфейс, при запросе которого я буду создавать соответствующий объект, его реализующий и возвращать, запоминая ссылку. Подсчет ссылок тоже не зря ведут отдельно для интерфейсов, когда он обнулится, я этот объект удалю. И все в шоколаде.

Serab

Serab

Пример самой простой QueryInterface которая создаёт объекты.

kokoc88

Да нету тут никакой темы COM-технологий, тут аналогия, знакомо тебе такое понятие?

kokoc88

Ну вот если я тут унаследую от C2, то будет вызван вариант, где кастуют к C2, а не default, предложи-ка реализацию с enum'ами такого поведения.

kokoc88

ты до конца дочитал сообщение?

Serab

Пример самой простой QueryInterface которая создаёт объекты.

interface IBase : IUnknown

{

...

};



interface IExtended : IUnknown

{

...

};



class Component : IBase

{

  HRESULT QueryInterface(...)

  {

     if (iid == IID_EXTENDED)

     {

        if (pExt == 0)

        {

           pExt = new ExtPart(...);

        }

        *ppv = pExt;

     } else ...

     (reinterpret_cast< IUnknown * >( *ppv ->AddRef;

     return S_OK;

  }

...

  class ExtPart : IExtended

  {

   ...

  };

private:

   IExtended *pExt;

};

Serab

Вернуть соответствующее enum значение.

kokoc88

Ну а как тогда я отличу C2 от его наследника? А никак.

Serab

Интересно, ты прикалываешься или серьёзно? Точно так же, как ты стал бы отличать их в случае dynamic_cast. В твоём случае добавился бы один dynamic_cast, в моём случае дописывается значение enum.

kokoc88

Serab

Я не вижу аналогии между эмуляцией полиморфизма через QueryInterface и задачей конкретизациии абстрактных классов.

kokoc88

А ты? Напиши реализацию функции getType в C2 и в наследнике, а потом покажи как твой switch зайдет в вариант для C2, если там наследник на самом деле.

Dasar

Во-первых, речь шла о Си++, на C# достаточно typeof. Во-вторых, такое решение стоит применять только в том случае, если операция, требующая конкретизации одна. В остальных случаях ты только навредишь таким подходом. В третьих, в Си++ нету чистых интерфейсов, там будут абстрактные классы и поставленную тобой задачу я решу очень быстро - просто реализовав функцию get_type во всех абстрактных классах. С точки зрения ООП это продолжает оставаться эквивалентом dynamic_cast. В четвёртых, стоило приводить примеры с множественным наследованием, геморой будет разве что там.

Serab

В этом коде не видно очень важной части. Я имею полное право сказать, что он написан с ошибкой.

Serab

Очень просто, get_type вернёт разные значения enum-а для базового класса и для наследника.

kokoc88

КАК ТОГДА твой switch узнает, что код для наследника C2 и код самого C2 как-то связаны? То-то, никак, об этом я тебе и толкую!

Serab

Чего? Лучше приведи пример кода с dynamic_cast, который я перепишу на enum-ы. (Поскольку я выше по теме уже подсказал про множественное наследование, я ожидаю, что приведённый код не будет его содержать.)

struct A

{

};



struct B : A

{

};



void f(A *p)

{

  if (dynamic_cast< B* >( p ) != 0)

    specific_to_B( p );

  else

    default_to_A( p );

}

  struct C : B {};

Serab

kokoc88

так код будет или нет?

        abstract class A1

        {

            public virtual TheEnum GetEnum

            {

                return TheEnum.E1;

            }

        }

слив засчитан.

kokoc88

Ну так что, где там _ошибка_ в моем наивном QueryInterface? Причем, где доказательство, что я не могу создавать объекты в QE? Да ты и не найдешь этого, т.к. так все и делают =)

Dasar

В Си++ и того проще, стереть "= 0" и добавить тело функции.

Dasar

// CppTest.cpp : Defines the entry point for the console application.

//



#include "stdafx.h"

#include <iostream>



struct IA

{

	virtual ~IA{}

};

struct IB:IA

{

	virtual int X = 0;

};

struct IC:IB

{

	virtual int Z = 0;

};



struct C:IC

{

	int X{return 5;}

	int Z{return 15;}

};



struct B:IB

{

	int X{return 5;}

};



struct A:IA

{

};



IA* GetA(int i)

{

	switch (i)

	{

	case 3:

		return new C;

	case 2:

		return new B;

	default:

		return new A;

	}

}



int _tmain(int argc, _TCHAR* argv[])

{

	int i;

	std::cin >> i;



	IA* a= GetA(i);



	IB* b = dynamic_cast<IB*>(a);

	if (b != NULL)

		std::cout << b->X << std::endl;



	IC* c = dynamic_cast<IC*>(a);

	if (c != NULL)

		std::cout << c->Z << std::endl;



	return 0;

}

kokoc88

Пейши аналог с enum'ами.

Serab

ты проэмулировал полиморфизм более сложным программным методом.

kokoc88

вообще это ты тут эмулируешь полиморфизм enum'ами, нет?

kokoc88

// DelCpp.cpp : Defines the entry point for the console application.

//



#include "stdafx.h"

#include <iostream>



enum the_type

{

	type_a,

	type_b,

	type_c

};



struct IA

{

	virtual ~IA { }



	virtual the_type get_type

	{

		return type_a;

	}

};



struct IB : IA

{

	virtual int X = 0;



	virtual the_type get_type

	{

		return type_b;

	}

};



struct IC : IB

{

	virtual int Z = 0;



	virtual the_type get_type

	{

		return type_c;

	}

};



struct C : IC

{

	int X { return 5; }

	int Z { return 15; }

};



struct B : IB

{

	int X { return 5; }

};



struct A : IA

{

};



IA* GetA(int i)

{

	switch (i)

	{

	case 3:

		return new C;

	case 2:

		return new B;

	default:

		return new A;

	}

}



int _tmain(int argc, _TCHAR* argv[])

{

	int i;

	std::cin >> i;



	IA* a = GetA(i);



	the_type type = a->get_type;



	if (type == type_b || type == type_c)

		std::cout << IB*)a)->X << std::endl;



	if (type == type_c)

		std::cout << IC*)a)->Z << std::endl;



	return 0;

}

  

Serab

enum EType
{
type_a,
type_b,
type_c
};
void f(A *p)
{
switch(p->get_type
{
default:
default_to_A( p );
break;
case type_b:
case type_c:
specific_to_B(static_cast<B*>(p;
break;
}
}

kokoc88

Нет-нет. Ты дурачком-то не прикидывайся =)
Ты напиши как у меня. Кто за тебя пройдется по коду и поправит все эти enum'ы?

Вердикт:
Не, ну ты реальне лошок, прочитал пару книжек, а вынес из них не очень-то много.

Dasar

kokoc88

в твоем же решении - и то, и другое резко подскакивает.

функция main могла не знать какие бывают классы реализации интерфейсов IA, IB, IC, и соответственно не менялась при добавление классов D, E, F и т.д.

соответственно, и цикломатическая сложность функции main, и coupling функции main были минимальны

Dasar

И да, я продолжаю считать, что с точки зрения ООП решения эквивалентны.

struct IA

{

	virtual ~IA{}

};

struct IB:IA

{

	virtual int X = 0;

};

struct IC:IB

{

	virtual int Z = 0;

};





int _tmain(int argc, _TCHAR* argv[])

{

	int i;

	std::cin >> i;



	IA* a= GetA(i);



	IB* b = dynamic_cast<IB*>(a);

	if (b != NULL)

		std::cout << b->X << std::endl;



	IC* c = dynamic_cast<IC*>(a);

	if (c != NULL)

		std::cout << c->Z << std::endl;



	return 0;

}

А что, у меня меняется? Ну разве что я промахнулся по клавиатуре, с кем не бывает.

struct ID:IC

{

	virtual int Q = 0;

};



struct D:ID

{

	int X{return 5;}

	int Z{return 15;}

	int Q{return 10;}

};

Serab

По крайней мере развёл тебя на ошибку в коде QI.

kokoc88

Ну-ка ну-ка, ты пока так и не сказал, что имеешь в виду.

kokoc88

при добавлении вот такого класса D функцию main надо переписывать

IA* GetA(int i)

{

	switch (i)

	{

	case 4:

		return new D;

	case 3:

		return new C;

	case 2:

		return new B;

	default:

		return new A;

	}

}



int _tmain(int argc, _TCHAR* argv[])

{

	int i;

	std::cin >> i;



	IA* a = GetA(i);



	the_type type = a->get_type;



	if (type == type_b || type == type_c)

		std::cout << IB*)a)->X << std::endl;



	if (type == type_c)

		std::cout << IC*)a)->Z << std::endl;



	return 0;

} 

Dasar

Почему? Вот я не переписал, она работает:

void another_main

{

	IA* a= GetA(i);



	IB* b = dynamic_cast<IB*>(a);

	if (b != NULL)

		std::cout << b->X << std::endl;



	IC* c = dynamic_cast<IC*>(a);

	if (c != NULL)

		std::cout << c->Z << std::endl;



	ID* d = dynamic_cast<ID*>(a);

	if (d != NULL)

		std::cout << d->Q << std::endl;



}

kokoc88

какой будет эквивалентный код?

Dasar

этом случае это было критично и является ошибкой.

Dasar

Какой будет код ты знаешь. Но теперь нам обоим пришлось переписать функцию.

kokoc88

ошибки еще нет, т.к. не указана реализация IUnknown-а у ExtPart

Serab

Я сказал - ты не привёл код QI у реализации IExtended. В этом случае это было критично и является ошибкой. Я тебе предлагаю ознакомиться с темой и написать тот же код со вторым методом QI у реализации IExtended.

Serab

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

kokoc88

напомню, что функцию main я не трогал.
а тебе придется ее потрогать.

kokoc88

У тебя что-то точно не в порядке с определением последовательности действий. Я _сначала_ написал код, и уже _после_ назвал тебя лошком.

Serab

class ExtPart : IExtended

{

private:

  Component *cmpnt;

public:

  ExtPart(Component *_cmpnt) : cmpnt( _cmpnt ) {}

  HRESULT QueryInterface(...)

  {

    if (id == IID_EXTENDED)

    {

       *ppv = static_cast<IExtended*>( this );

    } else if (id == IID_UNKNOWN) // тут честно не помню как называется константа GUID для IUnknown

    {

       *ppv = static_cast<IUnknown *>( cmpnt );

    } else if (id == IID_BASE)

    {

      *ppv = static_cast<IBase *>( cmpnt );

    } else ...

    

    (reinterpret_cast<IUnknown *>( *ppv ->AddRef;

    return S_OK;

  }



  void Release

  {

    if (--refcnt == 0)

    {

      cmpnt->pExt = 0;

      delete this;

    }

  }

};

kokoc88

Ладно, я сегодня добрый.

Хоть это и оффтоп, но вот тебе правильная реализация QI у ExtPart'а:

Serab

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

Serab

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

kokoc88

Это набросок реализации. И про композицию тут все знают, ты что, думаешь глаза тут кому-то открыл?

Ты давай по делу, а то это неправильно, то неправильно, а конкретно указать не можешь.

Serab

Это набросок реализации с существенными ошибками с точки зрения COM и языка Си++.

Serab

После таких набросков обычно не пишут слова типа "слив" и "лошок".

Serab

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

kokoc88

Какую ошибку? То, что ты видешь неточности в ненаписанном коде?

Serab

в технологии COM называется композицией

Serab

Ты забыл написать там несколько важных вещей.

Serab

существенными ошибками с точки зрения COM и языка Си++

Dasar

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

kokoc88

Во-первых, ты хотел сказать аггрегирование?

Serab

Это можно понять в зависимости от того, что вставлено в new ExtPart(...); Если там написано слово this, то в общем коде происходит обращение к освобождённой памяти.

Serab

неправильно посчитал ссылки

kokoc88

Коооод приведи.

	IBase* pb = new Component; // does addref once

	IExtended* pe;

	pb->QueryInterface(IID_EXTENDED, (void**)&pe);

	pb->Release; // base class is deleted here

	pe->Release; // access to freed memory

kokoc88

Думаешь я нормально не реализую подсчет ссылок?

Разговор был о том, что QI — не аналог dynamic_cast, потому что применим даже когда не происходит приведение между указателями на разные интерфейсы одного и того же C++ - объекта. Я это доказал. Ты дальше бесишься тут.

Serab

pb->Release; // base class is deleted here

Serab

В текущем коде ты его уже неправильно реализовал.

Serab

pe->Release; // access to freed memory

kokoc88

Неверно, потому что я не приводил реализации подсчета ссылок. В расширенной части привел, с ним какие проблемы?

Serab

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

kokoc88

Но кто сказал, что я тебя послушаю и сделаю тупо?

class ExtPart : IExtended

{

private:

  Component *cmpnt;

public:

  ExtPart(Component *_cmpnt) : cmpnt( _cmpnt ) {}

  HRESULT QueryInterface(...)

  {

    if (id == IID_EXTENDED)

    {

       *ppv = static_cast<IExtended*>( this );

    } else if (id == IID_UNKNOWN) // тут честно не помню как называется константа GUID для IUnknown

    {

       *ppv = static_cast<IUnknown *>( cmpnt );

    } else if (id == IID_BASE)

    {

      *ppv = static_cast<IBase *>( cmpnt );

    } else ...

    

    (reinterpret_cast<IUnknown *>( *ppv ->AddRef;

    return S_OK;

  }



  void Release

  {

    if (--refcnt == 0)

    {

      cmpnt->pExt = 0;

      delete this;

    }

  }

};

  

Serab

Тот факт, что ты сейчас можешь всё это замазать

Serab

Мне неважно, как ты сделаешь, мне важно, как ты уже сделал:

Serab

как ты уже сделал:

kokoc88

Свой код напиши, который это демонстрирует. Пока то что ты написал выше я разнес в клочья. Тот код делает предположение, что во _внешнем_ классе подсчет ссылок выполнен _неверно_. Это предположение делать глупо.

kokoc88

Приведи код.

	IBase* pb = new Component;

	IExtended* pe;

	pb->QueryInterface(IID_EXTENDED, (void**)&pe); // pb refcount == 2

	pb->Release;

	pe->Release; // pb was not freed

  

Serab

yroslavasako

Для расширяемости можно возвращать строку или guid, но опять же, с точки зрения проектирования это параллельн

kokoc88

Ладно, надо добавить еще строчку в этот Release. Я писал в форуме сразу и не проверял работу этого всего.

kokoc88

Александреску для расширяемости приводил пример с темплатными списками типов.

Serab

я могу лишь заметить, что dynamic_cast тоже может возвращать разные указатели (по значению).

Serab

Serab

Тот же, кто пройдётся по коду у тебя и поправит dynamic_cast-ы в случае, когда для B и C надо совершать разные действия.

kokoc88

все-таки QI - не семантический, а синтаксический аналог dynamic_cast

kokoc88

Нет, придется только если мне нужна специальная функциональность для C. А если меня устраивает работа с C как с B, то _ничего_ абсолютно менять не придется во внешнем коде. В случае же enum'ов придется походить, поисправлять.

Dasar

Решение с dynamic_cast/enum пригодно только в одном случае - когда операция с конкретными типами одна.

kokoc88

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

Dasar

Как это операция одна, если их уже несколько?

1. Напечатать погоду.

2. Покомандовать всплытием подводной лодки.

3. Выдать погоду в телетекст.

kokoc88

std::cout << weather.Display << std::endl;

if (weather.IsGood
submarine.Up;

Dasar

new CoutWeatherVisitor(cout)->Visit(weather);

new IsGoodWeatherVisitor(submarine)->Visit(weather);

new TeletexWeatherVisitor(teletex)->Visit(weather);

Dasar

Dasar

Теперь каждый класс погоды разрастается для всех операций.

std::cout << FormatForCout(weather) << std::endl;



if (IsGoodForUp(weather, submarine

  submarine.Up;



teletex << FormatForTeletex(weather) << std::endl;

kokoc88

а типа такой код - это верх удобства и расширяемости?

да, и можно несколько примеров из каких-нибудь стандартных библиотек твоего подхода?

значит надо сделать их внешними, да и всё

kokoc88

std::cout << FormatForCout(weather) << std::endl;

Dasar

Подход не мой - подход разработали другие люди и написали про него книжку.

Ivan8209

kokoc88

реальные примеры, давай.

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

kokoc88

А если эта книжка не является авторитетом, тогда что?

безо всяких искусственных конструкций.

Dasar

Вот сам и давай реальные примеры, где много операций над фиксированной иерархией сделано без Visitor.

kokoc88

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

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

основные примеры фиксированной иерархии являются парсеры/генераторы (очень я и упомянул в предыдущем посте).

или хотя бы реальные примеры применения фиксированных иерархий не для парсеров/генераторов?

Ivan8209

kokoc88

Питер Норвиг подойдёт?

Мне покласть на частные проблемы какого-то насильно пропихиваемого подхода.

Dasar

Кстати, можно мне примеры реальных приложений, где классы не имеют фиксированную иерархию? На C# это ведёт как минимум к генерации кода на лету, как я понимаю.

kokoc88

иерархия классов наследуемых от контрола - необозримое

любое приложение/библиотека работающие с коллекциями
иерархия классов, наследуемая от интерфейса коллекции, тоже необозримая.

Ivan8209

kokoc88

И так, у нас есть два так-себе примера, потому что модели в них слабо связаны с изначальной постановкой задачи. Я на 100% согласен, что Visitor там никуда не впился, ровно как и задача конкретизации абстракции. Это ты называешь "большинством"?

kokoc88

Здесь у меня ошибок нет

Тебе не нравится то, что твои переусложнённые конструкции никому
не нужны?

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

Dasar

Да? То есть ты в каждой своей программе наследуешься от интерфейса коллекции? Готовые не используешь? И почему оно там необозримо? Они каждый день добавляют новый способ сделать IList?

kokoc88

потому что каждая либа добавляет свой вариант коллекции

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

Dasar

Давай определимся более конкретно. Нам нужны примеры задач, где
1. Не фиксированная, постоянно меняющаяся иерархия классов.
2. Требуется добавлять операции над конкретными типами из иерархии.
3. Изменение иерархии происходит чаще, чем добавление новых операций.

Dasar

Её (задачи) нет, потому что операции с коллекцией фиксированы. Не требуется реализовывать всё новые и новые способы обойти коллекцию, или вставить в неё элемент. Да ещё и такие, которые бы зависели от конкретного типа этой коллекции. Поэтому Visitor тут не применим и не нужен.

Да ещё и такие, которые бы зависели от конкретного типа этой коллекции

Ivan8209

kokoc88

Зато ты очень помог своим "конкретным" советом. Да так, что вы
обсуждаете отлечённые вопросы уже две сотни сообщений.

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

kokoc88

winforms,
коллекции

Dasar

Не требуется добавлять новые операции в зависимости от реализации.

kokoc88

все наоборот.
конечно же операций над коллекциями как грязи(выборки, пересечения, группировки, фильтрации, синхронизации и т.д.) и они не фиксированы.
и есть куча библиотек стандартных и полустандартных для работы с коллекциями.
в C++ - - это как минимум <algorithm>,
в C#(из нового) - это system.linq.

и это тоже не так.
т.к. хотя бы банальная задача - получить кол-во элементов в коллекции - зависит от того, что перед нами - список(IEnumerable коллекция(ICollection массив, ассоциативный массив, частная коллекция и т.д.

kokoc88

так что system.linq тогда делает?

Dasar

это не добавление новой операции в интерфейс погоды

Dasar

kokoc88

так и вывод погоды - это уж точно тогда не новая операция над погодой.

kokoc88

т.е. вывод коллекции на экран - это не новая операция,
а вывод погоды на экран - это новая операция?
я правильно понял твою изощренную логику?

Dasar

Новая операция в данной теме - то, что требует изменения интерфейсов в иерархии классов. В том коде, который привёл автор есть коментарий "Новый метод, нету в предке!"

Чтобы обойти список или получить его элемент вовсе не требуется менять интерфейс IList.

kokoc88

так это часто бывает следствием плохой архитектуры классов.

это следствие хорошей архитектуры IList-а.

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

Ivan8209

kokoc88

"У тебя стоит задача конкретизировать абстракцию,"--- это не
помощь, ты обсуждаешь это уже две сотни сообщений и конца не
видно.

Поэтому я и считаю, заметь --- не один, что "погода" должна быть
простым агрегатным типом.

Ivan8209

kokoc88

Я его прочитал несколько раз, нет там никакой помощи, потому что
всё упирается в заявления, основанные на неправильном проектировании.

Ему и на это указали, чтобы привёл реальный пример.

Так что все ваши рассуждения являются отвлечёнными, основанными на такой же или похожей ошибке проектирования. Ну и где здесь помощь?

Dasar

Да? То есть единственно возможная иерархия - это когда базовый класс содержит все методы всех дочерних классов?

kokoc88

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

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

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

Ivan8209

kokoc88

"Погода" на самом деле простая запись, её незачем делить на
вымышленные подклассы.

То есть, ты считаешь, что если этот пример --- погода, проектировать не обязательно

Ладно, я понял, в чём заключается твоя "помощь."

Realist

Ivan8209

Dasar

Дайте знать, когда придете к консенсусу

Ivan8209

Serab

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

Dasar

Сможешь привести пример хотя бы трёх таких параметров?

Ivan8209

Dasar

Serab

Dasar

По поводу полей вообще всем уже давно ясно, что инкаспуляция решает и делать/не делать поля вопрос не стоит. Не?

Ivan8209

Ivan8209

Dasar

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

Serab

если же - использующий код наш же

Dasar

Я понимаю, что в этом треде в некотором роде модно уходить от темы, но в первом посте написано, что это не так =)

Serab

> По поводу полей вообще всем уже давно ясно, что инкаспуляция решает
Неверно.

Ivan8209

Dasar

Я понимаю, что в этом треде в некотором роде модно уходить от темы, но в первом посте написано, что это не так =)

Serab

там не сказано, приложения наши же или нет.

Dasar

Где ты в быту видел "классы," да ещё с какими-то наследованиями и иерархиями?

Ivan8209

Serab

Ты не задумывался о том, что, если ты закроешь доступ к
температуре и атмосферному давлению, то, что ты отдаёшь,
перестанет быть состоянием тропосферы, сиречь погодой?

Serab

Где ты в быту видел "классы," да ещё с какими-то наследованиями и иерархиями?
Может, ты ещё и числа видел?
Учи матчасть.

Dasar

Это позволит мне завтра

Serab

это разве не "преждевременная оптимизация"?

Ivan8209

Ivan8209

Dasar

Прямой доступ к полям обещает гораздо более неприятные последствия.