Есть некий класс, объект которого не должен уметь менять ничего в себе, то есть сам для себя он const.
Но есть другой класс, который может изменять эти объекты.

Как называется такая пара паттернов?

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

M>Есть некий класс, объект которого не должен уметь менять ничего в себе, то есть сам для себя он const.
M>Но есть другой класс, который может изменять эти объекты.

M>Как называется такая пара паттернов?

Это называется "инкапсуляция наоборот", а по-простому — п-дец. Первое место, где следует делать имутабельность — это как раз для внешних пользователей.

А, ммм. Поэтому это называется "кривой дизайн". Обычно наоборот делают, кто-то близкий может менять сущность, а кто-то далекий не может. Тогда есть ReadonlyInterface.

Какую задачу решаете, наверняка лучше есть решение?

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

LV>Какую задачу решаете, наверняка лучше есть решение?

Есть объект "стена". Внутри стены есть объекты "бревна". Бревно не может менять само себя. А вот стена при изменении геометрии меняет все бревна внутри себя.

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

M>Есть объект "стена". Внутри стены есть объекты "бревна". Бревно не может менять само себя. А вот стена при изменении геометрии меняет все бревна внутри себя.

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

Баблик Морозов кажется ?

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

IT>Лучше, если стена будет не менять брёвна, а заменять их новыми, более подходящими.

Нет, не лучше. Создание объекта — тяжелая операция. Редактирование — гораздо быстрее

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

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

IT>>Лучше, если стена будет не менять брёвна, а заменять их новыми, более подходящими.

M>Нет, не лучше. Создание объекта — тяжелая операция. Редактирование — гораздо быстрее

Там сделай immutable и так чтобы копирование было дешевле.

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

IT>>Лучше, если стена будет не менять брёвна, а заменять их новыми, более подходящими.

M>Нет, не лучше. Создание объекта — тяжелая операция. Редактирование — гораздо быстрее

Раздели объект на две части — константная и редактируемая. Получится нечто вроде Property Bag + Handle.

class Block : PropertyBag
{
...
}

class Wall
{
...
   public HandleCollection<Blocks> Blocks
...
}

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

IT>>Лучше, если стена будет не менять брёвна, а заменять их новыми, более подходящими.
M>Нет, не лучше. Создание объекта — тяжелая операция. Редактирование — гораздо быстрее

Это зависит от дизайна объектной модели. Можно спроектировать так, что создание объекта не будет тяжёлой операцией. Например, всю тяжесть вынести в другие объекты.

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

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

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

IT>>Лучше, если стена будет не менять брёвна, а заменять их новыми, более подходящими.

M>Нет, не лучше. Создание объекта — тяжелая операция. Редактирование — гораздо быстрее
После редактирования объекта никаких дальнейших операций типа обновления экрана не будет? Если будет, то ПМСМ, создание объекта это будет незаметная операция на фоне других.

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

LV>>Какую задачу решаете, наверняка лучше есть решение?

M>Есть объект "стена". Внутри стены есть объекты "бревна". Бревно не может менять само себя. А вот стена при изменении геометрии меняет все бревна внутри себя.

Ну значит и не нужна геометрия для бревна.

Log {
int getLenght() {
   return wall.getLenght();
}