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

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

S>>и чем же следующий хамелеон хуже?
S>>

S>>class Chameleon
S>>{
S>>    public Color skinColor { get; set; }
S>>}
S>>

J>Он попадает под описание процедурного стиля программирования: разбиение задачи программирования на набор переменных, структур данных и подпрограмм.

Как так? Отличия лишь в синтаксисе и такой глубокий вывод о стиле... Метод ChangeSkin заменен методом set_skinColor. Больше ничего не изменилось...
Кстати, не считаю, что процедурный стиль плох.
А если так?

class Chameleon
{
    public Color skinColor { get; }
}

S>>Не, ну это детский сад какой-то. Я предпочитаю опираться на принципы, сформулированные Кэйем. У него ничего нет про "данные и логика в одном объекте".

J>Алан Кэй пишет
J>

J>OOP to me means only messaging, local retention and protection and
J>hiding of state-process, and extreme late-binding of all things.

J>"local retention" — это и есть отсылка к тому что состояние объекта находится внутри объекта.

J>Там же он пишет:
J>

J>I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning – it took a while to see how to do messaging in a programming language efficiently enough to be useful).

J>Биологические клетки свое состояние держат внутри себя, имеют разный набор данных(митохондрии, рыбосому, цитозоль), имеют разное поведение, и общаются посредством передачи ионов и молекул через каналы.

Да, сокрытие состояние объекта таки приветствуется. Но есть некоторое "но". Анемик не пытается делать из всего объекты. В нем моделируется не поведение пользователя, а поведение сервиса, производящего над пользователем некие действия. Поведение обработчика доменного события, если угодно. Пользователь в нем — сообщение и не стоит рассматривать его поля как его состояние. Не более, чем символы — состояние (неизменяемой) строки.