Здравствуйте, Misha87, Вы писали:
M>Есть объект "стена". Внутри стены есть объекты "бревна". Бревно не может менять само себя. А вот стена при изменении геометрии меняет все бревна внутри себя.
Лучше, если стена будет не менять брёвна, а заменять их новыми, более подходящими.
Если нам не помогут, то мы тоже никого не пощадим.
Re: Константный для себя и неконстантный для другого
Здравствуйте, Misha87, Вы писали:
M>Здравствуйте, IT, Вы писали:
IT>>Лучше, если стена будет не менять брёвна, а заменять их новыми, более подходящими.
M>Нет, не лучше. Создание объекта — тяжелая операция. Редактирование — гораздо быстрее
После редактирования объекта никаких дальнейших операций типа обновления экрана не будет? Если будет, то ПМСМ, создание объекта это будет незаметная операция на фоне других.
Здравствуйте, Misha87, Вы писали:
M>Есть некий класс, объект которого не должен уметь менять ничего в себе, то есть сам для себя он const. M>Но есть другой класс, который может изменять эти объекты.
M>Как называется такая пара паттернов?
Это называется "инкапсуляция наоборот", а по-простому — п-дец. Первое место, где следует делать имутабельность — это как раз для внешних пользователей.
Re[5]: Константный для себя и неконстантный для другого
Здравствуйте, Misha87, Вы писали:
M>Здравствуйте, IT, Вы писали:
IT>>Лучше, если стена будет не менять брёвна, а заменять их новыми, более подходящими.
M>Нет, не лучше. Создание объекта — тяжелая операция. Редактирование — гораздо быстрее
Там сделай immutable и так чтобы копирование было дешевле.
Re[3]: Константный для себя и неконстантный для другого
Здравствуйте, Misha87, Вы писали:
LV>>Какую задачу решаете, наверняка лучше есть решение?
M>Есть объект "стена". Внутри стены есть объекты "бревна". Бревно не может менять само себя. А вот стена при изменении геометрии меняет все бревна внутри себя.
Ну значит и не нужна геометрия для бревна.
Log {
int getLenght() {
return wall.getLenght();
}
Есть некий класс, объект которого не должен уметь менять ничего в себе, то есть сам для себя он const.
Но есть другой класс, который может изменять эти объекты.
Как называется такая пара паттернов?
Re: Константный для себя и неконстантный для другого
А, ммм. Поэтому это называется "кривой дизайн". Обычно наоборот делают, кто-то близкий может менять сущность, а кто-то далекий не может. Тогда есть ReadonlyInterface.
Какую задачу решаете, наверняка лучше есть решение?
Здравствуйте, LeonidV, Вы писали:
LV>Какую задачу решаете, наверняка лучше есть решение?
Есть объект "стена". Внутри стены есть объекты "бревна". Бревно не может менять само себя. А вот стена при изменении геометрии меняет все бревна внутри себя.
Re[4]: Константный для себя и неконстантный для другого
Здравствуйте, Misha87, Вы писали:
IT>>Лучше, если стена будет не менять брёвна, а заменять их новыми, более подходящими.
M>Нет, не лучше. Создание объекта — тяжелая операция. Редактирование — гораздо быстрее
Раздели объект на две части — константная и редактируемая. Получится нечто вроде Property Bag + Handle.
class Block : PropertyBag
{
...
}
class Wall
{
...
public HandleCollection<Blocks> Blocks
...
}
Re[5]: Константный для себя и неконстантный для другого
Здравствуйте, Misha87, Вы писали:
IT>>Лучше, если стена будет не менять брёвна, а заменять их новыми, более подходящими. M>Нет, не лучше. Создание объекта — тяжелая операция. Редактирование — гораздо быстрее
Это зависит от дизайна объектной модели. Можно спроектировать так, что создание объекта не будет тяжёлой операцией. Например, всю тяжесть вынести в другие объекты.
В любом случае, это беспредметный спор без знания деталей твоего проекта. Одно можно сказать точно — не на ту дорожку ты свернул.
Если нам не помогут, то мы тоже никого не пощадим.