Здравствуйте, Ikemefula, Вы писали: I>Тогда что означает слово "oriented" ?
"ориентированный", нет?
Поймите, что есть языки с поддержкой OOP. Это не означает, что без них ООП невозможно.
Точно так же, как можно писать в процедурном стиле даже на ассемблерах без инструкции call. Просто это значительно более болезненно
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Enomay, Вы писали:
E>очень странно, так как идея размазывания по разным классам сервисов вам кажется хорошей идеей.
Ничего подобного. Вся необходимая логика компактно расположена внутри DiscountService и связанных с ним классов.
Если вы нарисуете диаграмму зависимости.
E>по-вашему у ордера задача только одна — хранить данные? интересное понимание ответственности. но пусть будет так.
Я вас тогда так спрошу: вы слово Single в аббревиатуре SRP как понимаете?
E>от того, что метод находится не в ордере, а в сервисе, ни метод, ни ордер, проще не становится.
Конечно же становится. Банальная математика. Уменьшая площадь поверхности класса Order, мы гарантированно упрощаем его разработку и тестирование.
E>в вашем случаи все методы работают только с внешними данными, у меня с внутренними. это решит проблему "закрытости", при необходимости.
Нет. В моём методе все методы, которые могут работать с внешними данными, остаются снаружи. Их не нужно перетестировать всякий раз, как мы меняем внутреннюю подробность реализации Order — достаточно протестировать внешний контракт Order.
S>>>>Вот например — мы только что договорились с производителем DVD-плееров, что будем давать плееры бесплатно при покупке телевизора. E>>>как это относится к логике расчета стоимости заказа? S>>Это и есть "расчёт стоимости заказа". В заказе две позиции — телевизор за 17000 и плеер за 2100. Сумма заказа — 17000, потому что плеер должен идти бесплатно. Если я купил только плеер — 2100. Два плеера — 4200.
E>ну и отлично. если купили телевизор, то плеер добавляется к ордеру с ценой 0. ордер вернет стоимость 17000. иначе цена будет другой.
Подождите, что значит "с ценой 0"? Вы мне только что рассказывали, что цену OrderLine берёт из Product.
Product у нас в двух заказах один и тот же.
Вопрос повышенной сложности: а что, если мы добавили в ордер сначала плеер, а потом телевизор? E>потому что вы не читаете то, что я пишу.
Я очень внимательно читаю то, как вы уклоняетесь от моих вопросов.
E>в объектной модели у нас ничего не изменилось. добавили товару в базе скидку и забыли. Ордер вернет правильную сумму заказа.
Код в студию можно?
E>все то, что вы ему приписали, кроме расчета общей стоимости заказа
Конкретнее.
E>>>все это отлично кладётся в ордер, где имхо ему и место. но вы в праве думать иначе. S>>Что именно "всё"? Логика по расчёту скидок? А почему в Order, а не в, скажем, Customer? E>наверное потому, что общая сумма заказа есть информация о самом заказе и относящаяся к нему? Хорошая попытка. Ок, предположим, что обязанность рассчитывать стоимость с учётом скидок вменена ордеру (пусть и в нарушение SRP).
Давайте посмотрим, куда это нас приведёт.
E>разве я против? делайте как вам удобнее
S>>В системе, написанной в моём подходе, достаточно заменить реализацию IDiscountService — а всё остальное останется работать. Гарантированно. S>>Потому что сами заказы в обеих кофейнях устроены совершенно одинаково. S>>В вашем подходе логика расчёта запихана в сам класс Order. Любое изменение там — это перетестирование класса, и всех зависимых от него классов.
E>глупости. а говорите что я не читаю ваши сообщения. а я ведь писал, что ордер кроме суммирования, фактически ничего не делает.
Подождите, ведь только что в ордере фигурировали скидки.
Давайте вы всё же приведёте пример кода, а то вы в одном месте пишете одно, и тут же рядом пишете нечто другое.
E>>>вот вот. просто я храню реализацию не там, где вы. она от этого несколько меняется, но хуже не становится. S>>Ну почему же "не становится". Ещё как становится. Производительность — ниже, стоимость внесения изменений — выше.
E>очень спорное и беспредметное утверждение.
Ну давайте оспорьте его.
S>>Ещё раз поясню, что подход, который я описываю — это ООП. Все черты ООП в нём в полный рост. Для микромагазинов на 5 товаров действительно можно оперировать рич моделью. E>в ООП так же входит то, что объект оперирует внутренним состоянием. у вас состояние и действия разнесены в разные места.
Нет, в ООП это не входит. Вас обманули. ООП вовсе не запрещает объекту общаться с окружающим миром.
E>я думаю это проблема не в рич подходе.
А в чём же?
E>мне кажется что для каждой задачи существует своё решение. а выбирать нужно из того, что лучше умеешь. я не сталкивался с конкретно вашими проблемами, но сталкивался с проблемами которые возникают от подобного подхода к реализации.
Ну расскажите про проблемы. Я вам набросал скетч решения для задачи "рассчитать сумму заказа с учётом скидок". E>особенно — логика в базе. но это все лирика.
Я пока ничего не говорил про логику в базе. Я вам даже привёл пример кода на C#.
E>в базе установлю. так же как и вы.
В какой базе? Ну напишите же уже пример кода. Вы так этому сопротивляетесь, что я начинаю думать, что вы просто не понимаете, как реально будет выглядеть ваш код.
E>я не вижу ничего плохого в решении задач вашим способом. если он вам ближе, то не стоит заморачиваться. E>на сегодняшний день я не вижу ничего плохого в рич модели. она хорошо справляется с моими задачами. а это увы, не интернет магазины. E>и в моем случае код получается достаточно логичный и структурированный. E>это касается реализации БЛ. где нужно будет анемик модель, будет анемик (в основном отображение данных).
Это очень хорошо. Осталось только отбросить заблуждения вроде того, что анемик != ООП. или что анемик = функциональный подход.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Enomay, Вы писали:
E>product.GetPrice() ?
E>при необходимости в этот метод можно передать еще что-то. например кол-во этих продуктов в заказе. от этого изменится возвращемое значение.
Экий вы ловкий. Ок, вот вы реализовали product.GetPrice. Теперь вас попросили внести в вашу систему скидку "купив два, третий — бесплатно". Естественно, для некоторых товаров.
И есть намёк на то, что завтра потребуются другие скидки, но пока точно непонятно какие (сделаем вид, что мы с Ikemefula не рассказали вам только что про десять других видов скидок).
Расскажите мне, как вы поменяете интерфейс класса Product, и как будет устроен его GetPrice().
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Lloyd, Вы писали:
L>С фига-ли?
Как с фига? Идентичность есть, поведение есть, состояние есть. Чего ещё? L>Может еще и очереди сообщений в ОО запишешь?
Нет, зачем? L>Да ладно уж, чего там мелочиться, давай и свободные процедуры/функции туда же до кучи.
Нет идентичности и возможности иметь поведение с предысторией (т.е. состояние).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
L>>С фига-ли? S>Как с фига? Идентичность есть, поведение есть, состояние есть. Чего ещё?
Идентичность чего с чем?
L>>Может еще и очереди сообщений в ОО запишешь? S>Нет, зачем?
Почему нет? В чем собственно отличие сервиса от очереди сообщений, если не принимать во внимание асинхронности,
L>>Да ладно уж, чего там мелочиться, давай и свободные процедуры/функции туда же до кучи. S>Нет идентичности и возможности иметь поведение с предысторией (т.е. состояние).
Здравствуйте, Lloyd, Вы писали: L>Идентичность чего с чем?
Более точным переводом identity является "идентифицируемость", но обычно переводят "идентичность".
У вас есть какие-то сомнения в том, что в SOA каждое обращение идёт к какому-то конкретному сервису?
L>Почему нет? В чем собственно отличие сервиса от очереди сообщений, если не принимать во внимание асинхронности,
Очередь — всего лишь механизм доставки. Кто разгребает очередь?
L>Поведение с предысторий — можно.
Можно, но получится собственно эмуляция ООП при помощи процедурного программирования (CFront помните?)
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Flem1234, Вы писали:
F>Здравствуйте, Lloyd, Вы писали:
S>>>>>Вообще-то нет. Кей напрямую идентичность не упоминает, но его messaging подразумевает возможность послать сообщение конкретному объекту, вне зависимости от его состояния. Так что без identity messaging не работает.
F>>>Как в SOA же нет состояния. F>>>Нет состояния — нет ООП.
L>>О том и речь, что утверждение "идентичность уже включено в понятие messaging", мягко говоря, сомнительно.
F>А как возможно отослать сообщение без адресата?
Адрес не есть Identity. За одним адресом может быть много identity, как в одной квартире могут проживать много человек.
Здравствуйте, Flem1234, Вы писали:
F>Здравствуйте, Lloyd, Вы писали:
L>>Здравствуйте, Sinclair, Вы писали:
L>>>>Ошибаешься S>>>Вообще-то нет. Кей напрямую идентичность не упоминает, но его messaging подразумевает возможность послать сообщение конкретному объекту, вне зависимости от его состояния. Так что без identity messaging не работает.
L>>т.е. SOA — это ООП? Или SOA — это не messaging?
F>Как в SOA же нет состояния.
Это неверно.
F>Нет состояния — нет ООП.
Это тоже неверно.
F>Нет ножек — нет мультиков.
???
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Lloyd, Вы писали: L>>Идентичность чего с чем? S>Более точным переводом identity является "идентифицируемость", но обычно переводят "идентичность". S>У вас есть какие-то сомнения в том, что в SOA каждое обращение идёт к какому-то конкретному сервису?
Снаружи нет возможности идентифицировать конкретный сервис, вернее экземпляр сервиса. Это и есть отсутствие идентичности.
Снаружи мы можем говорить только об эквивалентности. И с точки зрения SOA все сервисы с одинаковым контрактом эквивалентны.
Здравствуйте, Lloyd, Вы писали:
L>Посылка сообщения — это абстракция любого вызова, не только вызова методов объектов. Для примера, можешь поинтересоваться SOA и очередями сообщений.
В вики в статьях про MQ и message фигурируют отправитель и получатель
Например:
Message passing is a form of communication used in concurrent and parallel computing, object-oriented programming, and interprocess communication, where communication is made by sending messages to recipients. In a related use of this sense of a message, in object-oriented programming languages such as Smalltalk or Java, a message is sent to an object, specifying a request for action.
или
Message queues provide an asynchronous communications protocol, meaning that the sender and receiver of the message do not need to interact with the message queue at the same time. Messages placed onto the queue are stored until the recipient retrieves them.
Но даже если есть случаи, когда у сообщения нет получателя, то Алан Кей как раз имел в виду, что получатель есть.
Не могу понять, что ты хочешь доказать? Что ООП это не "идентифицируемые объекты общающиеся через сообщения друг к другу, и реагирующие на сообщения по разному в зависимости от внутреннего состояния"?
Здравствуйте, Sinclair, Вы писали:
S>Более точным переводом identity является "идентифицируемость", но обычно переводят "идентичность". S>У вас есть какие-то сомнения в том, что в SOA каждое обращение идёт к какому-то конкретному сервису?
У меня есть сомнение, что можно говорить об идентичности в случае когда речь идет об одном экземпляре.
L>>Почему нет? В чем собственно отличие сервиса от очереди сообщений, если не принимать во внимание асинхронности, S>Очередь — всего лишь механизм доставки. Кто разгребает очередь?
А какое это имеет значение?
L>>Поведение с предысторий — можно. S>Можно, но получится собственно эмуляция ООП при помощи процедурного программирования (CFront помните?)
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, samius, Вы писали:
I>>>Чужие мнения меня интересуют как ещё одна точка зрения. Предмет для дискредитации это отказ от прояснения своей точки зрения. Не совсем ясно, чего ты делаешь на профильном форуме, если отказываешься прояснить свою точку зрения S>>Я не желаю потратить на это месяц. А в твоем случае, меньшим, похоже не обойтись.
I>Можешь не тратить месяц — Синклер сделал то о чем я тебя просил всего за одно сообщение.
Вот и славно, спасибо Синклеру.
Так это была просьба? Я принял ее за предварительный диагноз.
I>Тренируйся.
Только меня не покидает ощущение того, что если бы ты о примере услышал от меня, то повел бы себя иначе.
Здравствуйте, Flem1234, Вы писали:
F>В вики в статьях про MQ и message фигурируют отправитель и получатель F>Например: F>
F>Message passing is a form of communication used in concurrent and parallel computing, object-oriented programming, and interprocess communication, where communication is made by sending messages to recipients. In a related use of this sense of a message, in object-oriented programming languages such as Smalltalk or Java, a message is sent to an object, specifying a request for action.
Ну продемонстрируйте, как из этого определения следует идентичность получателя.
Например, посылаю я широковещательный сетевой пакет, ну и кому я его посылаю? Или пишу сообщение в MQ, из кторой сосут десяток читателей, кто освоборится, тот и подхватить очередную порцию, кому тогда слался message, какова identity получателя?
F>Но даже если есть случаи, когда у сообщения нет получателя, то Алан Кей как раз имел в виду, что получатель есть. F>Не могу понять, что ты хочешь доказать?
А вы поднимитесь по ветке на пяток сообщений, там все есть.
F>Что ООП это не "идентифицируемые объекты общающиеся через сообщения друг к другу, и реагирующие на сообщения по разному в зависимости от внутреннего состояния"?
На основе чего вы сделали вывод, что я хочу доказать именно это?
F>
Ты под Павла со своими смайликами косишь что-ли? Право, не самый лучший образец для подражания.
Здравствуйте, Sinclair, Вы писали:
L>>В ветке, где обсуждается процедурность vs объектная-ориентированность более логично подчеркивать тот аспект которые отличает эти две парадигмы, а не тот, что их сближает. L>>В этом отношении определение ООП из википедии вполне корректно, а цитаты Алана Кея — совсем неуместны. S>В ветке происходит странная борьба между неправильным пониманием ООП и неправильным пониманием процедурного подхода.
S>Чтобы понять, почему анемик не является менее ООП, достаточно отойти чуть назад и задуматься. S>Постулат номер 1: ООП — оно не про моделирование задачи. Оно про моделирование решения.
S>Постулат номер 2: ООП не про данные, ООП про поведение.
Это какой-то новый совершенно выбивающий из колеи прием — я отвечаю на ваш пост, а вы в ответ приводите набор банальностей, на который и возразить вроде нечего.
Видимо если я вас спрошу, где связь, вы мне посоветуете опять перейти к чтению классиков?
Здравствуйте, gandjustas, Вы писали:
G>Снаружи нет возможности идентифицировать конкретный сервис, вернее экземпляр сервиса.
Зато есть возможность идентифицировать эндпоинт. И совершенно пофигу, сколько там за фасадом экземпляров реализации — на уровне контрактов этого не видно.
G>Снаружи мы можем говорить только об эквивалентности. И с точки зрения SOA все сервисы с одинаковым контрактом эквивалентны.
Если есть внутренний стейт — нет, не эквивалентны.
... << RSDN@Home 1.2.0 alpha 5 rev. 1530 on Windows 7 6.1.7601.65536>>
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Enomay, Вы писали:
E>>product.GetPrice() ?
E>>при необходимости в этот метод можно передать еще что-то. например кол-во этих продуктов в заказе. от этого изменится возвращемое значение. S>Экий вы ловкий. Ок, вот вы реализовали product.GetPrice. Теперь вас попросили внести в вашу систему скидку "купив два, третий — бесплатно". Естественно, для некоторых товаров. S>И есть намёк на то, что завтра потребуются другие скидки, но пока точно непонятно какие (сделаем вид, что мы с Ikemefula не рассказали вам только что про десять других видов скидок). S>Расскажите мне, как вы поменяете интерфейс класса Product, и как будет устроен его GetPrice().
как-то так.
это, конечно, тупая реализация, с опущенными вариантами получения разных типов скидок.
а скидки по конкретному продукту могут описываться хоть в XML.
само собой добавление товаров свыше 2х, которые бессплатные, не является обязанностью класса Order.
ведь это как в жизни. купил 2, но от 3го бессплатного отказался. не отказался? ок. расчет стоимости корзины все равно останется верным, в данном случае.
вся проблема в том, что мы смотрим на вещи по разному. в моем случае Order это грубо говоря корзина с продуктами, если быть точнее — чек.
а по этому мой класс Order работает как чек. и лишние товары со скидками, или бесплатные, он сам не добавляет. он считает то, что есть. а вот кто это добавит, не его проблема.
это и есть, на мой взгляд, SRP. каждый занимается тем, что лучше умеет.
кстати говоря, "купи 3 бутылки пива и 4ю бессплатно" можно рассматривать как 1 еденица товара. обычно они именно в таком виде и продаются. так что делать хитрые условия по скидке 4го товара, после предыдущих 3х, обычно нет необходимости.
ну а для уникальных случаев, конечно же, есть соответствующие решения.
E>>очень странно, так как идея размазывания по разным классам сервисов вам кажется хорошей идеей. S>Ничего подобного. Вся необходимая логика компактно расположена внутри DiscountService и связанных с ним классов. S>Если вы нарисуете диаграмму зависимости.
это отличается лишь местоположением, от моего подхода. и еще тем, что я работаю с теми данными, которые имею, а вы работаете с внешними.
E>>по-вашему у ордера задача только одна — хранить данные? интересное понимание ответственности. но пусть будет так. S>Я вас тогда так спрошу: вы слово Single в аббревиатуре SRP как понимаете?
я понимаю к чему вы клоните. но хранение данных для любого объекта, мне так всегда казалось, не является ответстветнностью. мой класс Order считает сумму позиций в, грубо говоря, ценнике. но ни в коем случае не печатает на принтере. учет скидок так же входит в расчет стоимости.
я считаю, что класс придерживается SRP.
если у вас другое мнение, вы в праве делать иначе
E>>от того, что метод находится не в ордере, а в сервисе, ни метод, ни ордер, проще не становится. S>Конечно же становится. Банальная математика. Уменьшая площадь поверхности класса Order, мы гарантированно упрощаем его разработку и тестирование.
но увеличиваем сложность и площадь сервиса. закон сохранения энергии, да. если что-то где-то пропало, то что-то появится в другом месте )
у меня логика лежит ближе к данным, на которые она распространяется. у вас наоборот, как я писал, данные отдельно, логика отдельно.
я не против такого решения, и там, где оно уместно, применяю. но если можно вырисовать красивую и функциональную рич модель, я это сделаю.
ну и про тестирование совершенно не аргумент. и тут и там метод. тестируются одинаково. как минимум. более того, у меня еще и разделено все на запчасти, каждая из частей может быть протестирована отдельно от общей инфраструктуры. сервисы обычно все же жощще завязаны.
E>>в вашем случаи все методы работают только с внешними данными, у меня с внутренними. это решит проблему "закрытости", при необходимости. S>Нет. В моём методе все методы, которые могут работать с внешними данными, остаются снаружи. Их не нужно перетестировать всякий раз, как мы меняем внутреннюю подробность реализации Order — достаточно протестировать внешний контракт Order.
масло масленое какое-то. методы которые работают с данными остаются снаружи, а что же тогда считает сумму заказа, если все данные с другой стороны.
E>>ну и отлично. если купили телевизор, то плеер добавляется к ордеру с ценой 0. ордер вернет стоимость 17000. иначе цена будет другой. S>Подождите, что значит "с ценой 0"? Вы мне только что рассказывали, что цену OrderLine берёт из Product.
а это уже зависит от того, как вы реализуете.
а если плеер добавили до телевизора, какая будет цена и как она будет считаться?
S>Product у нас в двух заказах один и тот же.
не всегда это так. это скорее некая копия продукта. ведь мы хотим хранить историю заказов? если будем хранить ссылку на оригинал, то при изменении его цены, у нас изменятся все заказы. а этого быть не должно.
S>Вопрос повышенной сложности: а что, если мы добавили в ордер сначала плеер, а потом телевизор?
да, это правда очень хороший вопрос. и я с ходу не готов дать на него ответ.
могу предположить, что при возрастающей сложности системы расчета заказа, всё это будет обрастать неимоверным кол-вом вспомогательных сервисов.
подозреваю что в некоторых случая, как этот, будет использоваться что-то вроде "итератор + посетитель", для некоторых правок.
опять же, это лишь вариант.
и он очень близко к вашему решению на основе сервисов.
E>>потому что вы не читаете то, что я пишу. S>Я очень внимательно читаю то, как вы уклоняетесь от моих вопросов.
некоторые вопросы на столько абстрактны и каверзны, что несколько отдаляются от действительности, а посему, и ответ на них найти не просто, а часто, и бессмысленно. мы рисуем схему к совершенно абстрактному магазину, требования к которому меняются ежесекундно. у вас есть готовое решение, я за вас рад.
E>>в объектной модели у нас ничего не изменилось. добавили товару в базе скидку и забыли. Ордер вернет правильную сумму заказа. S>Код в студию можно?
ну вот, еще один человек требует код.
но кода не будет. приведи я его вам, вы скажете "ага! а вот эта фишка в нем работать не будет", и будете совершенно правы, так как я не учел её, но лишь потому, что вы заранее её не упомянули.
именно по этой причине сие бессмысленно.
но, как я уже было предлогал, мы можем поставить задачу и представить 2 разных решения, а дальше вести обсуждении на основе их.
E>>все то, что вы ему приписали, кроме расчета общей стоимости заказа S>Конкретнее.
если вы вернетесь на пару постов назад, увидите, какие-то остатки, возвраты и прочую ерунду.
E>>глупости. а говорите что я не читаю ваши сообщения. а я ведь писал, что ордер кроме суммирования, фактически ничего не делает. S>Подождите, ведь только что в ордере фигурировали скидки.
а скидки не участвуют в подсчете суммы товаров заказа?
S>Давайте вы всё же приведёте пример кода, а то вы в одном месте пишете одно, и тут же рядом пишете нечто другое.
я где-то приводил небольшой абстрактный пример. возможно другому оппоненту.
пока не будет четкой задачи — не будет четкой реализации. вы то это должны понимать.
E>>очень спорное и беспредметное утверждение. S>Ну давайте оспорьте его.
не стану. потому что мне, на самом деле, это совершенно безразлично. пока такая проблема не стала, я не стану искать её решение. да и проблемы я не вижу.
E>>в ООП так же входит то, что объект оперирует внутренним состоянием. у вас состояние и действия разнесены в разные места. S>Нет, в ООП это не входит. Вас обманули. ООП вовсе не запрещает объекту общаться с окружающим миром.
конечно он может общаться с окружающим миром. разве я это запрещал? или говорил что кто-то другой запрещает?
но основная логика класса сконцентрирована на внутренних объектах.
возьмите объект Window в .NET. он ведь отрисовывает только свои контролы, а не чужие, правда?
E>>я думаю это проблема не в рич подходе. S>А в чём же?
в восприятии окружающего мира? )
E>>мне кажется что для каждой задачи существует своё решение. а выбирать нужно из того, что лучше умеешь. я не сталкивался с конкретно вашими проблемами, но сталкивался с проблемами которые возникают от подобного подхода к реализации. S>Ну расскажите про проблемы. Я вам набросал скетч решения для задачи "рассчитать сумму заказа с учётом скидок".
там другая задача, это далеко не интернет магазин, это тонны разнородных данных, которые нужно было агреггировать) но к делу это мало относится.
E>>я не вижу ничего плохого в решении задач вашим способом. если он вам ближе, то не стоит заморачиваться. E>>на сегодняшний день я не вижу ничего плохого в рич модели. она хорошо справляется с моими задачами. а это увы, не интернет магазины. E>>и в моем случае код получается достаточно логичный и структурированный. E>>это касается реализации БЛ. где нужно будет анемик модель, будет анемик (в основном отображение данных). S>Это очень хорошо. Осталось только отбросить заблуждения вроде того, что анемик != ООП. или что анемик = функциональный подход.
хотите отбросить — отбрасывайте. тот подход к реализации, что пропагандирует большинство, при работе с анемик моделью, лично я не считаю true OOP. но это ведь мое мнение, и я его никому не собираюсь навязывать.
я стараюсь использовать другой подход, по возможности, там где это уместно, либо третий, если не работают предыдущие два.
но зачем меня в чем-то убеждать, ума не приложу.
это больше похоже на то, что вы сами не уверенны, но если удастся убедить меня, то вы одержите победу над собой, и ваши сомнения развеятся. но увы, я останусь при своём
Идентичность есть, поведение есть, состояние есть. Чего ещё?
