Как получить свойство класса?

@skilllab · Регистрация: 03.02.2011

Студворк — интернет-сервис помощи студентам

В продолжении темы визитора

Есть, к примеру, вот такой код:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public interface IAnimals 
{
   string Name { get; set; } 
}
 
public class Dog : IAnimals
{
    public string Name { get; set; }
    public bool Ears { get; set; } = true;
}
 
public class Cat : IAnimals
{
    public string Name { get; set; }
    public bool Tail { get; set; } = false;
}
public class Squirel: IAnimals
{
    public string Name { get; set; }
}

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
var secondAnimal = new List<IAnimals>(){new Cat(), new Dog(), new Squirel()};
 
bool haveTail;
foreach (IAnimals currentAnimal in secondAnimal)
{
    if (currentAnimal is Cat)
    {
      haveTail = (currentAnimal as Cat).Tail;
      break;
    }
    if (currentAnimal is Dog)
    {
      (currentAnimal as Dog).Ears = true;
    }
}

Как нужно реализовать код, чтобы не использовать приведение типов при получении и установке значения свойства?

@Usaga · 15.06.2017, 10:03

skilllab, тег:

C#
1
public abstract Tag  Tag {get;}

... можно сделать не абстрактным, а обычным readonly-свойством. Просто заполнять его в конструкторе объектов. Так можно избавиться от ещё одного обращения к таблице виртуальных методов (буст скорости на полшишки). Но: тег не избавит от необходимости приведения типов, он просто покажет где кто в коллекции - не больше.

Так, что тут или визитёр или IS-ы.

Я когда проект просил имел в виду другое: может в вашем проекте можно обойтись без формирование общей коллекции классов одной иерархии. Тогда данная мутная тема стала бы неактуальной. Просто в такой подаче, как в примере выше иначе никак не поступить (если у нас такая коллекция существует обоснованно и никуда от неё не деться).

Есть ещё возможный вариант: свойства объектов хранить в коллекции (List<KeyValuePair> или Dictionary) в каждом объекте, тогда можно будет искать объекты по тегам (максимум производительности), но вообще ничего не кастить - коллекция будет описана в базовом классе. Это нечто похожее на PHP, но если свойства преимущественно мёртвым грузом лежат (не используются в бизнес-логике или контролы к ним руки свои грязные не тянут), то такое проканает.

@Storm23 · 15.06.2017, 10:26

Сообщение от skilllab

public enum Tag

Если уж городить огород с тегами, то вот так:

C#
1
2
3
4
5
6
7
8
9
    public abstract class Animal
    {
        public readonly Type Type;
 
        public Animal()
        {
            Type = GetType();
        }
    }

И затем:

C#
1
2
3
4
5
6
7
            foreach (Animal current in anim)
            {
                if (current.Type == typeof(Horse))
                {
                    //...
                }
            }

Хотя как по мне эти теги - извращение, лучше уж is/as.

И кстати, зачем вы оверрайдите все эти свойства - ID, Name?

Usaga, Насколько я понимаю, у автора набор примитивов, каждый с каким-то набором свойств. Эти наборы не являются классами в полном смысле слова. Они классы постольку-поскольку. Фактически автор работает не с объектами а с данными. Отсюда тяга к рефлекшену и работе с полями по имени, а не с объектами.

Сообщение от Usaga

свойства объектов хранить в коллекции

Я уже предлагал компонентную модель, которая решает проблемы автора.

@skilllab · 15.06.2017, 11:00 **[ТС]**

Сообщение от Usaga

может в вашем проекте можно обойтись

Проект не база данных. И с разработкой баз данных не связан. В проекте разве что дёргается некое значение с базы для заполнения одного- двух свойств сущностей.

В целом:
Есть сторонняя программа. В ней происходит формирование сущности, работа со свойствами сущности.
Изначально эта сущность с кучей свойств, универсальная. GOD класс, если перефразировать. Именно в таком виде с сущностью удобно работать в той программе. Сущность та хранится прям внутри отдельного рабочего файла той программы: т.е. сериализуется в бинар и запихивается внутрь некоего "хранилища" в физическом файле. Это 3rdParty для той программы. Т.е. файл той программы позволяет хранить данные НЕ программы, а вообще сторонние. Это нужно для того, чтобы таская файл по компам или по миру)) данные всегда были при файле.

Далее, с помощью уже моей программы, та сущность преобразовывается в набор классов => сущности с которыми удобно работать уже в моей программе. Если изначально была одна универсальная, то теперь она логически представляет из себя именно то, что должна. Там она имела просто enum-ы, характеризующие сущность в целом, то теперь стала полноценным объектом. В котором часть свойств перекочевала как есть, а часть преобразовалась в новую сущность. Так вот, исходя из тех enum-ов e у меня может быть строго определённое количество моих сущностей со своим набором уникальных свойств и поведения. Добавление новой - это не просто дописать класс, это прям нужно реально апгрейдиться. Тут на помощь приходит ГОСТ ))) у него строго регламентировано количество этих сущностей, у меня они все есть но не все используются)) кароч NotImplemented.
Так вот с этим своим набором сущностей я и работаю уже у себя в программе.

Если говорить предметно уже, то:
В той программе - есть деталь и сборочная единица (и то и то это физические файлы). Сборочная единица содержит в себе коллекцию деталей, либо может быть пустой, но при этом остаётся сборочной единицей.
И деталь и сборочная единица обладают набором свойств - тот самый GOD класс. Свойства к примеру: Обозначение, наименование, Материал, Покраска, Фамилии разработчиков и утверждающих.

В моей программе - деталь превращается в Деталь, её материал в Материал, т.е. у Материала Обозначение и Наименование - это свойства из Детали, но Материал теперь - это самостоятельная единица ибо Материал может быть и БЕЗ Детали. Или даже так может быть: Материал может быть получен из Детали, а благодаря манипуляциям пользователя Материал стал БЕЗ привязки к Детали, т.е. стал "виртуальной единицей" чисто у меня в программе. Дальше хуже))) у детали, как файла, может быть enum = Material. Это значит что GOD сущность преобразовывается прям сразу в Материал. У Материала, к примеру НЕ МОЖЕТ быть свойств фамилий разработчиков или свойства материал)). Так что поведение класса Материал очень отличается от поведения класса Деталь или Сборка.
Естественно по ходу работы в программе пользователь может изменять что угодно и как угодно. И даже больше ))) всю логику не описать - там ТЗ целое. Так что набор разношёрстных классов оправдан. И, кстати, путём обратного преобразования свойства из моих классов могут перекочёвывать в GOD класс обратно, нечто похожее на маппинг. Ибо как писал выше - GOD класс это именно то что нужно для работы ВНЕ моей программы, для работы в той программе. Это всё уже мои сущности.

Сама моя программа - это с виду DataGrid, разделённый на Разделы:

Документация

Сборки

Детали

Материалы

....

Коллекция для этой DataGrid - это набор разношёрстных классов ViewModel, представляющих мои сущности. Каждая моя сущность обладает своим поведением и своим набором свойств. В DataGrid всё более унифицированно для отображения. Т.е. у Детали ячейка Обозначение Материала берётся как свойство в VM "Деталь.Материал.Обозначение", у Материала Обозначение берётся как "Материал.Обозначение". Это как-то так...вкратце )))

Так вот пробегаясь по коллекции из этих ViewModel-ей, мне нужно знать с какой именно ViewModel-ю я работаю, и в зависимости от этого уже устанавливать или брать значение для бизнес-логики. Нельзя установить свойство Разработал классу Материал ))) ибо материал тупо не обладает таким свойством в отличие от Детали.

Добавлено через 58 секунд

Сообщение от Storm23

Я уже предлагал компонентную модель

может быть я тогда не совсем понял всех глубин её глубин.

покопаюсь.

@Storm23 · 15.06.2017, 11:20

Сообщение от skilllab

В целом:...

Ну то есть у вас есть плоская таблица (список god объектов) которую вы мапите на некую структуру классов. Одни свойства идут в один класс, другие - в другой. Декомпозиция. При чем тип классов не постоянен и зависит от enum-ов. Это понятно.
Проблема то в чем? Что вы такое пытаетесь с этим делать, что у вас появляются все эти монструозные as/is, визиторы и т.д.?
В чем суть проблемы? (только не говорите что суть проблемы в касте, опишите проблемы более широко, каст - это способ решения а не проблема)
Да, и пример кратенький этого god объекта и декомпозиции желательно привести.

@Usaga · 15.06.2017, 11:43

Сообщение от Storm23

В чем суть проблемы?

Возможно, что проблема в том, что ТС выложил свой пример с IS и спросил, нормально ли так делать. А я спросил: "По другому никак? Это решение - не очень". Ну и понеслись визитёры-шмизитёры.

Добавлено через 3 минуты
Storm23, вообще, мне изначально не понравилась задумка разделять данные на отдельные классы, чтобы потом всё равно выяснять кто где, потому я и зацепился.

@skilllab · 15.06.2017, 11:56 **[ТС]**

Сообщение от Storm23

Что вы такое пытаетесь с этим делать, что у вас появляются все эти монструозные as/is, визиторы и т.д.?

GOD класс он на то и GOD класс. Это как коробка с карандашами и фломастерами)) Для транспортировки, продажи, обмена - он удобен. Как только всё приходит к художнику - то тот работает с каждым карандашом и фломастером отдельно.
Карандаш обладает твёрдостью, фломастер содержанием спирта. Так и у меня: если всё содержимое вывалить на стол и сгруппировать, то к каждому субъекту рисования нужно применить правило получения или задания его свойства. Тут и возникает каст. Ну не обладает карандаш спиртосодержанием)) И помещение в класс Карандаша этого свойства, хоть null хоть empty - просто нелогично.

С самим GOD классом напрямую тоже низя работать. Иначе там количество флагов и enum-ов может перевалить за десяток. Это я говорю уже с высоты переделки модели по некоему ТЗ (а как известно ТЗ и реальность это бывает оторванные друг от друга вещи) раз 5.

Добавлено через 1 минуту

Сообщение от Usaga

не понравилась задумка разделять данные на отдельные классы

тут логика:

Сообщение от skilllab

у Детали ячейка Обозначение Материала берётся как свойство в VM "Деталь.Материал.Обозначение", у Материала Обозначение берётся как "Материал.Обозначение"

Добавлено через 6 минут

Сообщение от Storm23

Одни свойства идут в один класс, другие - в другой. Декомпозиция

Фактически да - декомпозиция. Но с точки зрения модели - задекомпозитированные классы, это уже самостоятельные сущности, никак не связанные с GOD классом. И сразу упреждаю вопросы - нет нельзя уйти от GOD класса. Он та самая рабочая сущность именно для нужного момента времени. Полученные классы вообще могут в последствии обходиться сами по себе полностью. Передача данных от GOD класса в мои сущности и обратно - это именно маппинг.

@aquaMakc · 15.06.2017, 13:22

Поправьте, если я не прав...
У ТСа проблема в том, что у него изначально неправильная архитектура модели данных, реализующая антипаттерн "Божественная сущность". А всё остальное - костыле-ориентированное программирование с попыткой разрулить кривую модель в жёстко структурированную логику.

@skilllab · 15.06.2017, 14:40 **[ТС]**

aquaMakc, не прав.
Забудьте о существовании GOD класса )) он служит лишь для получения данных. Представьте его просто как поставщика огромной кучи данных, которые нужно обработать. Я привёл его для понимания модели.

Сообщение от Storm23

Ну то есть у вас есть плоская таблица (список god объектов)

Нет. У меня таблица, отражающая разношёрстные по своей сути классы. Я же выше код с Animal привёл. Вот представьте что List<Animal> отражён в таблице. Не по порядку. Сгруппированно по признаку класса. Внутри групп сгруппировано по свойству Name. Пользователь видит лишь лошадок да зайчиков. Для него это просто строка таблицы. Для меня это разные сущности (ибо у лошадок нет пушистости, а у кроликов нет копыт) с имеющимися общими свойствами (к примеру Name, ID, Tag).

Добавлено через 58 минут

Сообщение от Usaga

можете сотворить кастрированный вариант, демонстрирующий идею и потребность в обсуждаемом.

Я уж, наверное, надоедаю))) но можете, пожалуйста, на том примере показать работу визитёра как видите её именно вы? Там в "хотелке" всё что хочется

И всё - отстану.

@Usaga · 16.06.2017, 04:31

Сообщение от skilllab

В моей программе - деталь превращается в Деталь, её материал в Материал, т.е. у Материала Обозначение и Наименование - это свойства из Детали, но Материал теперь - это самостоятельная единица ибо Материал может быть и БЕЗ Детали. Или даже так может быть: Материал может быть получен из Детали, а благодаря манипуляциям пользователя Материал стал БЕЗ привязки к Детали, т.е. стал "виртуальной единицей" чисто у меня в программе. Дальше хуже))) у детали, как файла, может быть enum = Material. Это значит что GOD сущность преобразовывается прям сразу в Материал. У Материала, к примеру НЕ МОЖЕТ быть свойств фамилий разработчиков или свойства материал)). Так что поведение класса Материал очень отличается от поведения класса Деталь или Сборка.
Естественно по ходу работы в программе пользователь может изменять что угодно и как угодно. И даже больше ))) всю логику не описать - там ТЗ целое. Так что набор разношёрстных классов оправдан.

Вот мы и докопались до правды. До самой сути проблемы. Сутее некуда.

GOD-класс, который получается из стороннего приложения создан таким только для удобства (если клея унюхаться) хранения. По своей сути, все выделенные из него классы не имею между собой ничего общего. У них тупо нет и не может быть общего предка, это совершенно разные сущности. Может иметь место агрегация или композиция, но уж точно не наследование.

"Деталь" содержит ссылку на "Материал", но это не делает их родственными классами. "Сборка" может содержать ссылку на список деталей, но это опять же композиция. А вы пытаетесь увидеть в них что-то общее. Вот вам и корень проблемы. Именно это я и предполагал в самом своём первом ответе на ваш вопрос в прошлой теме.

Все эти классы были свалены в кучу не потому, что они про одно. Нет. Просто кто-то решил, что ему так удобнее хранить данные. Всё в одной свалке.

skilllab, вы имеете дело с разными классами. Им не место в одной коллекции. Нужно пересмотреть их взаимоотношения исходя из ТЗ и предметной области. Вполне может статься, что тут имеет место чистый агрегат включающий все классы. Тогда никаких визитёров, рефлексий и IS\AS. Коллекция будет хранить только один кореневой класс (корень агрегации, агрегат - терминов много), а все эти сущности будут доступны через типизированные свойства или методы.

@skilllab · 16.06.2017, 07:00 **[ТС]**

Строчил строчил сообщение)) а потом метро ушло под землю во время отправки.
Короче, тут уже вступает "не надо слов, покажите мне код".

но его весь не могу. А часть, или "упрощённо", на первой странице, внизу.
Скажем так: в данной теме я разбираюсь с визитером.

@Usaga · 16.06.2017, 07:02

skilllab, тут уже не нужен код. Судя по вашему более детальному описанию, иерархии классов тут просто нет. У вас или композиция должна быть, или отдельные коллекции под отдельные классы. Никакой визитёр тут уже не уместен.

@skilllab · 16.06.2017, 07:05 **[ТС]**

Пысы: god класс ни при чём. Вообще. Зря вы за него цепляетесь, хотя я даже блин просил этого не делать. После старта моей программы у меня вообще нет god классов в коде))

Добавлено через 2 минуты
Композиция есть. Охх. Просто помогите пожалуйста с визитером на примере того класса, который я по вашей просьбе, накидал.
Спасибо.

@Usaga · 16.06.2017, 07:12

skilllab, GOD класс тут действительно не причём. Сами подумайте, каким боком должны быть связаны "Деталь", "Материал" и "Документация". С моей точки зрения: никак. То, что у них пару свойств совпадает родственности им не добавляет. Это просто разные классы и всё.

Добавлено через 3 минуты
Я же вам уже "накидывал" пример. Тоже с животными было.

@skilllab · 16.06.2017, 07:13 **[ТС]**

Классы являются всего лишь записями в одном списке. Об чём и речь. Они друг другу не родные никак.

@Usaga · 16.06.2017, 07:15

Сообщение от skilllab

Они друг другу не родные никак.

Тогда они не должны лежать в одном списке.

Добавлено через 17 секунд
Для чего они были в один список положены?

Добавлено через 34 секунды
Мы близки к по настоящему правильному решению вашей задачи.

@skilllab · 16.06.2017, 07:17 **[ТС]**

Я же вам уже "накидывал" пример.

ясно. Тогда вы помогли всем чем только можно с тем абстрактным примером, который не делал то что мне надо (хотя мог бы) и у которого совпали семантически имена классов с классами этой темы))

@Usaga · 16.06.2017, 07:20

skilllab, почему он вам ничего не дал? Вы не поняли, как в методах визитёра разместить логику работы с объектами?

@skilllab · 16.06.2017, 08:02 **[ТС]**

Для чего они были в один список положены?

Может и близки к разгадке. У классов есть 15 свойств(у каждого класса) , которые описывают одно и то же для таблицы. + у каждого класса есть свои уникальные свойства. Штук 10 у каждого. Какие то из уникальных свойств являются базовыми (типа как у детали, всё что касается её материала, вынесено в отдельный класс. А в детали он свойство). Какие то одни и те же общие свойства у одного класса просто автосвойство, у другого составное - но и там и там это свойство описывает одно и то же по смыслу. Есть ещё методы с одним и тем же названием. Ну и у них соответственно, у всех общий интерфейс

назовём его ISpecItem.
Тут дальше загвоздка может быть в том, что я для каждого своего класса использую разные ViewModel (мне нужна обертка прям обязок)

Добавлено через 10 минут
Но если бы была одна ViewModel, тогда б она стала GOD классом в штук over500 строк кода

да и с null значениями. Ибо, как писал ранее, у классов Material, Paint, Documentation .. просто нет свойства SignedPeople (свойство-класс), которое есть у класса Part. Оно уникально только для Part. И это приведено в пример только одно! свойство

Добавлено через 8 минут

Сообщение от Usaga

почему он вам ничего не дал?

Опять по новой? ))) ВОТ ТУТ "хотелка". В вашем абстрактном примере есть только Visit() который что-то там может делать в классах. Да блин, у него же даже смысл в этом, у паттерна Visitor. Вы мне посоветовали прикрутить его как получатель свойства в текущий код (уход от cast). Или как установитель свойства в конкретном классе. Но не показали как а написали что-то вроде "там всё просто - погугли" "в визитере вся логика" ...
Storm23, показал КАК можно вытащить свойство. Psilon намекнул КАК можно установить одно свойство передав параметр. У вас же я спрашиваю ваше видение визитера, на что вы меня отсылаете опять к своему ультра_супер_утрированному примеру где визитёр что-то там (какие то методы) вызывает внутри классов.

Добавлено через 4 минуты

Сообщение от Usaga

Вы не поняли, как в методах визитёра

Я не понял как с помощью визитёра получить свойство одного конкретного класса из коллекции разношерстных классов в текущий код, а так же не понял как с помощью визитёра установить значение свойства (значение находится во вне класса, значение находится ДО перебора коллекции) в конкретном классе при переборе разношерстных классов. Делов то ...

А я никак...

Добавлено через 4 минуты

Сообщение от Storm23

Я уже предлагал компонентную модель, которая решает проблемы автора.

Не могли бы вы чуть более конкретно кинуть гуглоссылкой)) по этой теме? Ну или на примерчик какой показательный.

@Usaga · 16.06.2017, 08:26

Сообщение от skilllab

Может и близки к разгадке. У классов есть 15 свойств(у каждого класса) , которые описывают одно и то же для таблицы. + у каждого класса есть свои уникальные свойства. Штук 10 у каждого. Какие то из уникальных свойств являются базовыми (типа как у детали, всё что касается её материала, вынесено в отдельный класс. А в детали он свойство)

Вот это меня выбило просто. Часть уникальных свойств является базовыми. Это как?

Насколько я понял, у вас вообще разные классы. 15 общих свойств вы завели тупо для того, чтобы отображать всё это в одном DataGrid? Это так?

Я не показывал более конкретный пример потому, что не мог от вас добиться конкретики. Установка или чтение свойства - это часть некоторой логики, вы мне её не показывали\не описывали. Я настаивал на том, что нужно в визитёр выносить не чтение\установку свойства, а всю логику, в которой данное действие происходит. Чуете разницу?

@skilllab · 16.06.2017, 08:28 **[ТС]**

Сообщение от Usaga

является базовыми. Это как?

C#
1
2
3
4
5
6
7
8
9
10
public class Part
{
    public SignPeople SignPeople {get;set;}
}
 
public class SignPeople 
{
   public string Designer {get;set;}
   public string Manager {get;set;}
}

Новые блоги и статьи Все статьи Все блоги /
FPS контроллер с анимированными Y-Bot и 3D-звуком miniaudio (Box3D, Recast, BehaviorTree.CPP, ozz-animation, ImGui, OpenGL и SDL3) 8Observer8 18.10.2026 Содержание блога \| English Version Полное мультиплатформенное руководство по стартовому проекту с FPS-контроллером игрока, анимированными роботами Y-Bot с 4-слойным блендингом, 3D-физикой Box3D,. . .	Локальный http сервер Argus19 17.10.2026 Локальный http сервер На работе, на двух локальных компьютерах круглосуточно работают программы опроса приборов с записью в книги Excel,которые раз в сутки записываются на сервер компании. Т. к. . . .	Копировать Windows на новый диск на UEFI damix 17.10.2026 https:/ / uriesk. wordpress. com/ 2016/ 11/ 01/ move-window-10-to-ssd-on-a-uefi-dualboot-system-with-basic-linux-tools/ TL DR Вставляем диск, а старый подключаем через переходник, грузимся с лайва. . .	ИИ не может найти нужный язык в списке Supersumestria 05.10.2026 Я ему даю вот такое изображение и прошу найти и подчеркнуть немецкий язык. Возвращает он вот это: https:/ / i. **********/ vqBWLe2. png Нужную строчку в 3й колонке просто выдумал. . Это. . .
Новая последняя моя музыка в SUNO zorxor 05.10.2026 Здравствуйте, дорогие мои друзья! С большой радостью я хотел бы представить вам свою новую последнею музыку, которую сгенерировала мне по моей просьбе нейросеть SUNO. С уважением, zorxor. Это. . .	Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .	Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .

@aquaMakc 484 / 397 / 68 Регистрация: 14.02.2014 Сообщений: 1,930
	15.06.2017, 13:22
	Поправьте, если я не прав... У ТСа проблема в том, что у него изначально неправильная архитектура модели данных, реализующая антипаттерн "Божественная сущность". А всё остальное - костыле-ориентированное программирование с попыткой разрулить кривую модель в жёстко структурированную логику. 0

@skilllab 296 / 236 / 58 Регистрация: 03.02.2011 Сообщений: 2,051 Записей в блоге: 1
	16.06.2017, 07:00 [ТС]
	Строчил строчил сообщение)) а потом метро ушло под землю во время отправки. Короче, тут уже вступает "не надо слов, покажите мне код". но его весь не могу. А часть, или "упрощённо", на первой странице, внизу. Скажем так: в данной теме я разбираюсь с визитером. 0

@Usaga 14811 / 9584 / 1368 Регистрация: 21.01.2016 Сообщений: 36,099
	16.06.2017, 07:02
	skilllab, тут уже не нужен код. Судя по вашему более детальному описанию, иерархии классов тут просто нет. У вас или композиция должна быть, или отдельные коллекции под отдельные классы. Никакой визитёр тут уже не уместен. 0

@skilllab 296 / 236 / 58 Регистрация: 03.02.2011 Сообщений: 2,051 Записей в блоге: 1
	16.06.2017, 07:05 [ТС]
	Пысы: god класс ни при чём. Вообще. Зря вы за него цепляетесь, хотя я даже блин просил этого не делать. После старта моей программы у меня вообще нет god классов в коде)) Добавлено через 2 минуты Композиция есть. Охх. Просто помогите пожалуйста с визитером на примере того класса, который я по вашей просьбе, накидал. Спасибо. 0

@Usaga 14811 / 9584 / 1368 Регистрация: 21.01.2016 Сообщений: 36,099
	16.06.2017, 07:12
	skilllab, GOD класс тут действительно не причём. Сами подумайте, каким боком должны быть связаны "Деталь", "Материал" и "Документация". С моей точки зрения: никак. То, что у них пару свойств совпадает родственности им не добавляет. Это просто разные классы и всё. Добавлено через 3 минуты Я же вам уже "накидывал" пример. Тоже с животными было. 0

@skilllab 296 / 236 / 58 Регистрация: 03.02.2011 Сообщений: 2,051 Записей в блоге: 1
	16.06.2017, 07:13 [ТС]
	Классы являются всего лишь записями в одном списке. Об чём и речь. Они друг другу не родные никак. 0

@Usaga 14811 / 9584 / 1368 Регистрация: 21.01.2016 Сообщений: 36,099
	16.06.2017, 07:20
	skilllab, почему он вам ничего не дал? Вы не поняли, как в методах визитёра разместить логику работы с объектами? 0