Похоже, это флеймоопасная тема (надо же какая игра слов ), так что заранее приношу свои извинения и призываю не начинать спор, а просто просветить меня, в чем заключается смысл понятий stateful и stateless и в чем суть их противопоставления. Как эти концепции проявляются и влияют на программы, и какие именно программы.

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

I>Похоже, это флеймоопасная тема (надо же какая игра слов ), так что заранее приношу свои извинения и призываю не начинать спор, а просто просветить меня, в чем заключается смысл понятий stateful и stateless и в чем суть их противопоставления. Как эти концепции проявляются и влияют на программы, и какие именно программы.

СТРОГО ИМХО:

stateful — модель, при котором объект содержит информацию о своем состоянии, все методы работают в контексте его состояния. (идеологически ближе к обычному полниманию объекта в терминат ООП).

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

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

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

I>>Похоже, это флеймоопасная тема (надо же какая игра слов ), так что заранее приношу свои извинения и призываю не начинать спор, а просто просветить меня, в чем заключается смысл понятий stateful и stateless и в чем суть их противопоставления. Как эти концепции проявляются и влияют на программы, и какие именно программы.

S>СТРОГО ИМХО:

S>stateful — модель, при котором объект содержит информацию о своем состоянии, все методы работают в контексте его состояния. (идеологически ближе к обычному полниманию объекта в терминат ООП).

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

И все? Это практически и следует из названия... Т.е. все сводится к процедуры vs объекты? Я разочарован

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

I>И все? Это практически и следует из названия... Т.е. все сводится к процедуры vs объекты? Я разочарован

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

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

S>>stateful — модель, при котором объект содержит информацию о своем состоянии, все методы работают в контексте его состояния. (идеологически ближе к обычному полниманию объекта в терминат ООП).

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

I>И все? Это практически и следует из названия... Т.е. все сводится к процедуры vs объекты? Я разочарован

Чуть-чуть не так. И то и то относится к объектам. Это проще показать на примере. Допустим нам нужен некий сервис (CircleDrawer), который будет рисовать окружности. Определим для него интерфейс.

В stateless варианте этот сервис НЕ хранит в себе информацию о окружности, которая в данный момент рисуется.

// stateless
interface CircleDrawer {
    public void drawCircle(int x, int y, int radius);
}

CircleDrawer drawer = ...
// использование
drawer.drawCircle(x, y, radius);

В stateful -- информация об окружности сохраняется между вызовами.

// stateful
interface CircleDrawer {
    public void setCircleCenter(int x, int y);
    public void setCircleRadius(int radius);
    public void drawCircle();
}

CircleDrawer drawer = ...
// использование
drawer.setCircleCenter(x, y);
drawer.setCircleRadius(radius);
drawer.drawCircle();

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

S>>>stateful — модель, при котором объект содержит информацию о своем состоянии, все методы работают в контексте его состояния. (идеологически ближе к обычному полниманию объекта в терминат ООП).

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

D>Чуть-чуть не так. И то и то относится к объектам. Это проще показать на примере. Допустим нам нужен некий сервис (CircleDrawer), который будет рисовать окружности. Определим для него интерфейс.

[skipped]

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

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

S>А в чем разница? Именно про эту разницу в поведении и было сказано. А то, что оба понятия могут быть отнесены к объектам — да, согласен. см.выше мою цитату.

Разница между твоим ответом и моим? Ни в чем. Я тебе и не возражаю. А просто дополняю и уточняю.

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

S>А в чем разница? Именно про эту разницу в поведении и было сказано. А то, что оба понятия могут быть отнесены к объектам — да, согласен. см.выше мою цитату.

Меня смутило "Т.е. все сводится к процедуры vs объекты?". Если ответить на этот вопрос однозначно утвердительно, то далее можно сделать поспешный вывод, stateless -- это не объектно-ориентированно, а значит плохо. Вот я и попробовал не дать сделать такой вывод.

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

I>Похоже, это флеймоопасная тема (надо же какая игра слов ), так что заранее приношу свои извинения и призываю не начинать спор, а просто просветить меня, в чем заключается смысл понятий stateful и stateless и в чем суть их противопоставления. Как эти концепции проявляются и влияют на программы, и какие именно программы.

Классическим примером stateful реализации является библиотека iostream.

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

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

Абстрактный пример.

class Statefull
 {
   Implementation imp;

   int a;
   int b;

  public:

   void setA(int a_) { a=a_; }
   void setB(int b_) { b=b_; }

   void method1(int x) { imp.method1(a,b,x); }
   void method2(int x) { imp.method2(a,b,x); }
   void method3(int x) { imp.method3(a,b,x); }
   void method4(int x) { imp.method4(a,b,x); }
 };

class Stateless
 {
   Implementation imp;

  public:

   void method1(int a,int b,int x) { imp.method1(a,b,x); }
   void method2(int a,int b,int x) { imp.method2(a,b,x); }
   void method3(int a,int b,int x) { imp.method3(a,b,x); }
   void method4(int a,int b,int x) { imp.method4(a,b,x); }
 };

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

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

S>>А в чем разница? Именно про эту разницу в поведении и было сказано. А то, что оба понятия могут быть отнесены к объектам — да, согласен. см.выше мою цитату.

D>Меня смутило "Т.е. все сводится к процедуры vs объекты?". Если ответить на этот вопрос однозначно утвердительно, то далее можно сделать поспешный вывод, stateless -- это не объектно-ориентированно, а значит плохо. Вот я и попробовал не дать сделать такой вывод.

Имхо stateless процедуры не являются объектно-ориентированными в обычном смысле. Их можно отнести к некоторому классу только условно, в качестве функции-хелпера (в С++). Смысл такого отнесения к классу является произвольным решением программиста, следствием логики программы и сущностей, которые она представляет, а не реальной связью между функциями. С таким же успехом это могли бы быть просто отдельные функции. Разве нет?

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

D>Меня смутило "Т.е. все сводится к процедуры vs объекты?". Если ответить на этот вопрос однозначно утвердительно, то далее можно сделать поспешный вывод, stateless -- это не объектно-ориентированно, а значит плохо. Вот я и попробовал не дать сделать такой вывод.

"это не объектно-ориентированно, а значит плохо" — это общий фетиш последнего времени, диагноз, так сказать.


ЗЫ. Это сообщение — не ответ на именно Ваше сообщение, а общее замечание по всей ветке.

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

Во! Может ты ответишь и на вопрос, который мне покоя уже давно не даёт?

Вариант 1.

class Circle{
    public property double radius;
    public property point2D center;
    public void draw( deviceContext dc, color c );
}

Вариант 2.

class CircleDrawer {
    public property double radius;
    public property point2D center;
}
void drawCircle( Circle c );

Вопрос. Почему первый вариант это кошерное ООП, а второй — процедурность поганая. Я в этой фигне сумел углядеть исключительно синтаксические отличия.

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

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

T>Во! Может ты ответишь и на вопрос, который мне покоя уже давно не даёт?

T>Вопрос. Почему первый вариант это кошерное ООП, а второй — процедурность поганая. Я в этой фигне сумел углядеть исключительно синтаксические отличия.

Если это вопрос ко мне, то я не совсем понял, почему я должен отстаивать позицию, которой не придерживаюсь. Тем более, что те два примера, что ты привел, не совсем равнозначны в смысле показа различий между stateless и stateful.

Что касается тех примеров, что я приводил, то они оба, на мой взгляд, вполне объектно-ориентированы (да, и stateless тоже). Хотя? если брать во внимание мои личные предпочтения, то мне больше нравится stateless вариант.

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

I>Похоже, это флеймоопасная тема (надо же какая игра слов ), так что заранее приношу свои извинения и призываю не начинать спор, а просто просветить меня, в чем заключается смысл понятий stateful и stateless и в чем суть их противопоставления. Как эти концепции проявляются и влияют на программы, и какие именно программы.

Stateless-объект можно удалить мгновенно после его использования и создать за мгновение до его использования. В то время когда его не используют ему существовать не обязательно. Ну, а данные он берёт, скажем, из базы данных, из сети, с диска и т.п., т.е. данные не внутри него, а где-то в другом месте — он лишь обертка, интерфейс, представитель кого-то другого.

Stateful-объект, должен существовать между двумя последовательными обращениями к нему, просто потому что он хранит данные непосредственно внутри себя.

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

D>Если это вопрос ко мне, то я не совсем понял, почему я должен отстаивать позицию, которой не придерживаюсь. Тем более, что те два примера, что ты привел, не совсем равнозначны в смысле показа различий между stateless и stateful.

Да не, они к stateful&stateless отношения вообще никакого не имеют. Этот вопрос просто меня мучает. Мучает тем, что я различий не вижу, а другие, неглупые вроде люди, встают на дыбы, мол если не метод, то это нарушение всех мыслимых законов божиих.

D>Что касается тех примеров, что я приводил, то они оба, на мой взгляд, вполне объектно-ориентированы (да, и stateless тоже). Хотя? если брать во внимание мои личные предпочтения, то мне больше нравится stateless вариант.

Ладно. Разговора не получится. У нас полностью совпадают точки зрения.

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

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

T>Во! Может ты ответишь и на вопрос, который мне покоя уже давно не даёт?

T>Вариант 1.
T>

T>class Circle{
T>    public property double radius;
T>    public property point2D center;
T>    public void draw( deviceContext dc, color c );
T>}
T>

T>Вариант 2.
T>

T>class CircleDrawer {
T>    public property double radius;
T>    public property point2D center;
T>}
T>void drawCircle( Circle c );
T>

T>Вопрос. Почему первый вариант это кошерное ООП, а второй — процедурность поганая. Я в этой фигне сумел углядеть исключительно синтаксические отличия.

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

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

Поэтому в Вашем случае 2-й вариант был бы для Бьярне предпочтительнее, если закрыть глаза на то ужасное обстоятельство, что данные объявлены как публичные члены

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

T>Вопрос. Почему первый вариант это кошерное ООП, а второй — процедурность поганая. Я в этой фигне сумел углядеть исключительно синтаксические отличия.
Абсолютно неверный вопрос, потому как абсолютно неверный пример.
1. ООП, а лучше говорить ООD предназначен не для маленьких примеров типа Hello World. Он не для этого создавался. Он предназначен для больших проектов в котором много сущностей. И здесь выявляется его мощность. И твой кошерный пример может быть минимум в трех видах, и очень зависит от окружения, остальных сущностей, и их поведения.
2. ООП, а лучше говорить OOD — это не просто теоретический бред в виде полиморфизма, абстракции и бла-бла. Это набор вполне конкретных методов и паттернов дизайна для построения приложений. Это не просто синтаксис написания объекта. Иначе бы он никому не был нужен.

С уважением, Gleb.

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

I>Насколько я помню, Страуструп советует функции, которые не нуждаются в доступе к внутренним данным объекта и ограничиваются доступом к публичному интерфейсу класса, объявлять как внешние функции класса (т.н. функции-хелперы), но в том же модуле (файле). Это позволяет избежать ненужной связи между такой функцией и классом и таким образом уменьшить сложность кода.
Да-да, так и есть, только Страуструп давно не является пророком ООП. Его конек — мультипарадигменное проектирование.

А в мэйнстриме (Ява и Шарп) совбодных функций нет, ибо так "объектно-ориентированней получается". Не так давно человек в форуме С++ спрашивал, можно ли точку входа в настройках линкера так настроить, чтобы при старте программы метод некоторого объекта вызывался. По той же причине, так объектно-ориентированней. Промыли людям мозги, что делать.

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

I>Насколько я помню, Страуструп советует функции, которые не нуждаются в доступе к внутренним данным объекта и ограничиваются доступом к публичному интерфейсу класса, объявлять как внешние функции класса (т.н. функции-хелперы), но в том же модуле (файле). Это позволяет избежать ненужной связи между такой функцией и классом и таким образом уменьшить сложность кода.

Я вполне с ним согласен. Чрезвычайно толковый мужик.

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

I>>Насколько я помню, Страуструп советует функции, которые не нуждаются в доступе к внутренним данным объекта и ограничиваются доступом к публичному интерфейсу класса, объявлять как внешние функции класса (т.н. функции-хелперы), но в том же модуле (файле). Это позволяет избежать ненужной связи между такой функцией и классом и таким образом уменьшить сложность кода.

T>Я вполне с ним согласен. Чрезвычайно толковый мужик.

Страуструп -- безусловно.

Только вот это -- на счет интерфейсов и связанности, по-моему, на совести Саттера.
Да и на счет уменьшения связанности, нет ее, имхо, совсем. Если только функция не шаблонная. А если шаблонная, то это уже duck typing называется.