Что-то не могу понять как он работает. По-идее, в конце рефакторинга надо еще добавить методы на запись во вновь созданный ссылочный класс. Или я что-то не могу понять смысл этого рефакторинга 
Я думал как – бывает 2 типа классов – значения и ссылочные. Первые отличаются от вторых тем, что их нельзя модифицировать, только создавать новые. А вторые можно менять. Но с изменением проблема – приходится согдавать там ивенты, чтобы синхронизировать изменения в них с другими зависимыми классами.
Так вот – в конце данного рефакторинга, ни методы на запись, ни ивенты не создаются. У кого какие мылси по этому поводу? Мне кажется, что я зря парюсьи просто что-то упустил 
7 марта 2008 в 9:05
Да, я забил на рефакторинг и сделал по интуиции
Просто разрешил свойства на запись и сделал события об изменении этих свойств 
И подписал кого надо на эти изменения.
6 марта 2008 в 23:05
Ага, понятно, про что ты. Обрати внимание, на первом рисунке ромбик заштрихованный, залитый чёрным. В этом случае говорят, что Order "владеет" Customer, или Customer – это "часть" Order. Скорее всего, Customer либо создаётся в конструкторе Order, либо в этот конструктор передаётся ссылка на только что созданный объект. Как это могло получиться.Изначально, создавая класс для заказа, отвели там переменную: имя заказчика. Потом, заказчика выделили в самостоятельный класс, и получилось так, что каждому заказу стал соответствовать один заказ, несмотря на то, что одному и тому же заказчику могут быть адресованы несколько заказов. Именно для учёта этого случая и предназначен данный рефакторинг. Итак, во втором случае Customer cуществует совершенно независимо от Order, который хранит только ссылку на него. Ну, к примеру, есть некий набор (коллекция) этих самых заказчиков, а мы, создавая заказ, устанавливаем в него только ссылку на один из её элементов.
6 марта 2008 в 23:05
Насчёт наблюдателя – теперь понял, вроде всё логично: визуализатор отслеживает изменения в модели, выступая в роли подписчика происходящих в модели событий.
Но тогда я совершенно не понимаю, в чём же суть проблемы
)
6 марта 2008 в 8:00
2Жека: с радостью почитаю
вышли, пожалуйста, на nepomnyashih@gmail.com . Классы действительно – не просто коллекция и итем, а специфичные для задачи 
. В итеме может быть ссылка на его парент. Например, для иерархического списка – у каждого подсписка есть ссылка на его контейнер. Или как у класса Control.
2Дмитрий: я говорю про //www.refactoring.com/catalog/changeValueToRefe...
Насчет коллекции – если мне нужно на экране дерево нарисовать? Т.о. есть model – дерево со своими св-ми и т.д. про него-то я и спрашиваю изначально. И есть его view – базовый класс граф и от него унаследовано уже это самоехитрое дерево, которое наблюдает за коллекцией
5 марта 2008 в 22:04
Согласен, особенно мне понравилось про "коллекцию, которая отображается на экране по паттерну наблюдатель"
)
5 марта 2008 в 22:03
Для рефакторинга SICP не нужен – он нужен для того, чтобы не возникало соблазна городить такие ужасы, как рассказал автор
5 марта 2008 в 21:01
Имеется в виду ведь вот это?
//www.refactoring.com/catalog/replaceDataValueW...
Нету тут никакой недосказанности. Я не знаю, что там у Вас с вашими умными тулзами и С#, делается это руками ровно за две минуты, и SICP при всём уважении тут не нужен.
Идея: раньше в классе хранили, просто, скажем, имя человека. Сейчас у нас появилсядля человека специальный класс, в котором есть имя. Рефакторинг: там, где хранили просто имя, теперь храним ссылку на класс, описывающий человека, в том числе и его имя. Диаграмма UML по приведённой ссылке описывает это просто, как угол дома.
Мы тут с коллегами устроили группу такую, там правда, чё-т активность пропала, видимо, все считают, что в рефакторинге есть недосказанность…
) Приглашаю туда обсудить эти вопросы. Лично я не считаю рефакторинг панацеей, но для ООП это достаточно неплохая практика.
//vkontakte.ru/club369013
5 марта 2008 в 11:01
Что за "хранилище, которое упоминается в книжке"? Что за "фабричный метод"?
Что-то не так тут скорее с проектированием – хранить в элементе ссылку на коллекцию – очень плохой тон, это разрушает сразу кучу свойств как коллекций, так и элементов, убивает кучу возможностей абстракции и, опять же, рефакторинга, и т.п. В общем, это оправдано лишь в исключительно редких случаях, когда и коллекция, и элементы – что-то очень специфическое (не какой-нибудь стандартный ArrayList) и гарантированно, по условию задачи, стопудово связанное только M:1 и ни при каких обстоятельствах не иначе, и когда элементы очень сильно связаны между друг другом. По-моему, в общем, единственный use-case – графы, и то не всегда. Даже при наличии связей, лучше хранить отдельно элементы, отдельно связи.
Не зацикливайся на паттернах
Не помню, я тебе уже слал книжку SICP? Если нет, то давай пришлю.
5 марта 2008 в 9:01
Конкретно, проблема такая: есть класс-значение A. Обычно объекты этого класса хранятся в коллекции С. Причем в А есть ссылка на С. Т.о. в проге происходит вот что – создаю коллекцию, создаю А с параметром С. Добавляю А в С. Ну и коллекция С отображается на экране по паттерну наблюдатель.
А сейчас, надо сделать, чтобы А стал ссылочным типом. И т.к. там все равно есть ссылка на коллекцию, в которой он хранится, то логично в качестве хранилища, которое упоминается в книжке, использовать С.
Но тогда в фабричном методе надо добалять А в С сразу. Но раньше-то я везде уже итак добавлял А в С
Вот мне и кажется, что что-то не так с этим рефакторингом. Какая-то недосказанность.
З.Ы. Я использую визуал студию
И язык C#. Студия не поддерживает этот рефакторинг. Просто C# поддерживает ивенты. Но это просто паттерн обсервер.
5 марта 2008 в 9:00
Мысль – книжка "рефакторинг" далеко не так полезна, как ее расписывают. Она ценна в плане терминологии, но слепо следовать ей – глупо.
Ты понимаешь, зачем нужен этот рефакторинг, и его общую идею? Тогда отложи книжку в сторону и делай
Если какие-то проблемы – выскажи их целиком и конкретно в отрыве от этого рефакторинга, помо(гу/жем)
Из последнего абзаца у меня сложилось впечатление, что ты используешь какую-то IDE, поддерживающую этот рефакторинг – я правильно понял?