ElisDN · June 28, 2019 10:10 · Jun 28, 2019 · Jun 28, 2019 · Jun 28, 2019
diff --git a/vo-entity.md b/vo-entity.md
@@ -8,6 +8,6 @@
 
 В итоге в приложении появляется куча абстрактных VO-типов для описания разных элементов: Point, Name, Phone, Address и т.п. И теперь нам нужно создать записи двух конкретных клиентов нашей фирмы в справочнике. Для этого мы делаем new Client(name1, phone1, address1) и new Client(name2, phone2, address2) и сохраняем в справочник для дальнейшего существования в нашей системе. Но проблема в том, что в одном доме могут жить люди с одинаковым именем, телефоном и адресом. Чтобы их не путать их записям надо выдумать более-менее уникальную комбинацию или присвоить точно уникальные дополнительные (суррогатные) номера (вроде ИНН), чтобы записывать и доставать из хранилища по этой комбинации или номеру. 
 
-Поэтому сущность – это созданный и долго существующий в нашей системе (имеющий цикл жизни) уникальный конкретный экзепляр-запись, который мы храним и достаём по **уникальному ключу**. И эта запись в нашем справочнике для одного клиента должна быть единственный, чтобы не создать случайно две записи для одного человека.
+Поэтому сущность – это созданный и долго существующий в нашей системе (имеющий цикл жизни) уникальный конкретный экзепляр-запись, который мы храним и достаём по **уникальному ключу**. И эта запись в нашем справочнике для одного клиента должна быть единственной, чтобы не создать случайно две записи для одного человека.
 
 Так что мы создаём, храним и сравниваем уникальные сущности по ключу. А объекты-значения просто используем для удобства как примитивы-значения и нигде отдельно не храним.
diff --git a/text.md → vo-entity.md b/text.md → vo-entity.md
diff --git a/text.md b/text.md
@@ -0,0 +1,13 @@
+Есть строка-значение, есть число-значение, есть структура-значение, есть объект-значение. Названо объектом и советуется использовать потому, что у объекта есть не только состояние, но и **поведение**.  То есть туда, в отличие от примитива или структуры, можно впрограммировать **свою логику**. Даже если в языке String – объект, то там всё равно есть только стандартные методы, а не наши собственные. Чтобы добавить своё поведение нужно либо обернуть примитив в свой объект, либо отнаследоваться.
+
+Например, тобы не возиться отдельно с float x и float y можно придумать свой тип Point(float x, float y) и добавить туда свой метод move(dx, dy). И потом добавить Vector(Point start, Point end) с add(Vector other). И Poligon(points) с методами добавления точек.
+
+Так что Value Object – это просто продвинутый пользовательский тип в виде объекта с пользовательским поведением. И эти значения мы создаём в любом количестве, сравниваем, передаём в функции и возвращаем оттуда также, как работаем с оригинальными int, float и string.
+
+Примитивы во многих языках иммутабельны и передаются по значению (копируется само значение), а объекты по указателю (копируется ссылка тот же объект). И изменение объекта в одном месте нечаянно затрагивает все остальные. Так что чтобы со всеми ими работать однообразно и безопасно таким объектам рекомендуется имитировать примитивность через клонирование и иммутабельность.
+
+В итоге в приложении появляется куча абстрактных VO-типов для описания разных элементов: Point, Name, Phone, Address и т.п. И теперь нам нужно создать записи двух конкретных клиентов нашей фирмы в справочнике. Для этого мы делаем new Client(name1, phone1, address1) и new Client(name2, phone2, address2) и сохраняем в справочник для дальнейшего существования в нашей системе. Но проблема в том, что в одном доме могут жить люди с одинаковым именем, телефоном и адресом. Чтобы их не путать их записям надо выдумать более-менее уникальную комбинацию или присвоить точно уникальные дополнительные (суррогатные) номера (вроде ИНН), чтобы записывать и доставать из хранилища по этой комбинации или номеру. 
+
+Поэтому сущность – это созданный и долго существующий в нашей системе (имеющий цикл жизни) уникальный конкретный экзепляр-запись, который мы храним и достаём по **уникальному ключу**. И эта запись в нашем справочнике для одного клиента должна быть единственный, чтобы не создать случайно две записи для одного человека.
+
+Так что мы создаём, храним и сравниваем уникальные сущности по ключу. А объекты-значения просто используем для удобства как примитивы-значения и нигде отдельно не храним.
No results found