|
Обратиться к полю родительского класса
|
|||
---|---|---|---|
#18+
Здравствуйте! Есть класс Group, где указываются два поля: список Element и Тип группы. Есть класс Element и там есть метод Method1, который присваивает значение в поле Result в зависимости от типа группы. C# Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61.
В данном случае метод Method1 запускаем не в классе Group, где известен тип группы, а именно в классе Element. Это просто тестовый пример, чтобы понимать как обращаться к определенному полю родительскому класса. Приходит идея написать так: C# Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28.
Скажите, как можно правильно обратиться к полю родительского класса? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 17:29 |
|
Обратиться к полю родительского класса
|
|||
---|---|---|---|
#18+
ferzmikk Обратиться к полю родительского класса Дальше не читал ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 17:35 |
|
Обратиться к полю родительского класса
|
|||
---|---|---|---|
#18+
ferzmikk Это просто тестовый пример ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 17:40 |
|
Обратиться к полю родительского класса
|
|||
---|---|---|---|
#18+
ferzmikk Получается в списке в каждом элементе будет присутствовать ссылка на целый объект класса Group. И? В чем проблема? Что смущает в хранении ссылки на целый экземпляр класса? ferzmikk Скажите, как можно правильно обратиться к полю родительского класса? Здесь нет никакого родительского класса, есть просто некий класс, хранящий список других классов. Отношение родитель/потомок тут и близко не пробегало. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 20:33 |
|
Обратиться к полю родительского класса
|
|||
---|---|---|---|
#18+
если время жизни родительского объекта равно времени жизни порожденного, то в обратной ссылке нет ничего страшного, использовать надо не поля, а свойства. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 20:34 |
|
Обратиться к полю родительского класса
|
|||
---|---|---|---|
#18+
Взаимная ссылка классов друг на друга всегда чревата граблями, вплоть до утечки памяти. Здесь ТС пытается создать именно циклическую ссылку. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 20:47 |
|
Обратиться к полю родительского класса
|
|||
---|---|---|---|
#18+
ferzmikk Скажите, как можно правильно обратиться к полю родительского класса? Может озвучите исходную задачу? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 23:18 |
|
Обратиться к полю родительского класса
|
|||
---|---|---|---|
#18+
Код с паблик-полями должен на ревью сразу отправляться в треш. На такой косяк, как "высовывание" наружу из класса коллекции в виде List<T> при этом уже можно даже и не смотреть. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 23:30 |
|
Обратиться к полю родительского класса
|
|||
---|---|---|---|
#18+
Shocker.Pro Взаимная ссылка классов друг на друга всегда чревата граблями, вплоть до утечки памяти. Здесь ТС пытается создать именно циклическую ссылку. Так GC ведь, какие проблемы. В тех же моделях EF взаимные ссылки по navigation properties сплошь и рядом. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 23:34 |
|
Обратиться к полю родительского класса
|
|||
---|---|---|---|
#18+
fkthat Так GC ведь, какие проблемы. В тех же моделях EF взаимные ссылки по navigation properties сплошь и рядом. Что ваяет ТС мы не знаем ... |
|||
:
Нравится:
Не нравится:
|
|||
18.05.2020, 23:42 |
|
Обратиться к полю родительского класса
|
|||
---|---|---|---|
#18+
Shocker.Pro в EF сущности не содержат логики и уничтожаются вместе с контекстом. Что ваяет ТС мы не знаем Что значит "уничтожаются"? Это же не С++ с оператором delete. В винформс, еще, кстати, циклические ссылки тоже повсюду, потому то любое использование events это неявная циклическая ссылка. Собственно, это есть один из огромных плюсов GC, что ему такие вещи нипочем. Если бы мы жили в мире где все структуры строго иеархические без циклических ссылок, то c головой хватило бы обычного reference counting, как в COM. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 00:58 |
|
Обратиться к полю родительского класса
|
|||
---|---|---|---|
#18+
Shocker.Pro из-за этого не получается дать дельный совет. hVostt Может озвучите исходную задачу? Задачу, которую решаю, - пробую написать нейронную сеть на C#. Пока простую. Я знаю, что для написании нейросети больше всего подходит Python с соответствующими библиотеками. На Python разрабатывал. Учитывая, что Python медленный. Cоздаешь класс Neuron с двумя свойства: входящие нейроны и веса. В классе Layer присутсвует свойство List<Neuron> и свойство Type. Перечисление Type имеет значения Input, Hidden и Output. Учитывая, что в одном нейроне надо делать расчеты, то надо учитывать Type нейрона и поэтому в класс добавил свойство Type. Но все равно иметь Type в двух классах не логично, если в одном слое указали определенный тип слоя, то входящие нейроны в этой слой имеет такой же тип. Поэтому задался вопросом: во втором классе не задавать Type и подумать как внутри класса Neuron можно определить Type оптимальным способом. Тут еще многое зависит как задашь архитектуру проекта для нейронной сети (не архитектура самой нейронной сети, где задается количество слоев, количество нейронов в каждом слое). Если данную задачу сложно решить и/или значительно повлияет на производительность компьютера, то можно тогда уж не усложнять, в классе Neuron оставить свойство Type. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 08:57 |
|
Обратиться к полю родительского класса
|
|||
---|---|---|---|
#18+
ferzmikk, Тут полиморфизмом очень сильно попахивает, хотя бы уже судя по множественным ветвлениям на основе значения Type. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 09:24 |
|
Обратиться к полю родительского класса
|
|||
---|---|---|---|
#18+
У меня была аналогичная ситуация в WPF-проекте, кода нужно было хранить ссылку на родительский объект. Код: c# 1. 2. 3. 4. 5. 6. 7. 8.
Во View была коллекция BaseContaiter, внутри каждого соответственно была своя коллекция Item. Нужно было реализовать Drag-and-Drop Item из одного BaseContaiter в другой, соответственно чтобы в том BaseContaiter, из которого перетащили этот элемент удалился, а в тот, который перетащили-добавился. Метод Drag-and-Drop получает в себя только экземпляр Item, соответственно из какого он BaseContaiter-неизвестно. Тогда делал ссылку в Item на BaseContaiter. Это работало, но очень редко всеже бывали неотлавливаемые и невоспроизводимые баги, причиной которых я подозреваю эту схему. Сейчас сделал бы еще один прокси объект, что-то вроде словаря, в котором бы хранилась информация к какому BaseContaiter относится каждый Item и все операции по перемещению производил бы через него, но от ссылок на класс контейнер отказался, потому что логика очень сильно размазывается по многим объектам. Может есть еще более классный вариант, но я пока додумался только до второго. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 09:43 |
|
Обратиться к полю родительского класса
|
|||
---|---|---|---|
#18+
ferzmikk Учитывая, что в одном нейроне надо делать расчеты, то надо учитывать Type нейрона и поэтому в класс добавил свойство Type. Как сказали выше, это решается полиформизмом с абстрактным методом расчёта. Создаёте наследников-нейронов конкретного типа, которые сами знают как себя вычислять. Другой подход, это мост. По сути нейрон содержит ссылку на метод вычисления, а не тип. Наследование дешевле, мост дороже, но гибче. ferzmikk Если данную задачу сложно решить и/или значительно повлияет на производительность компьютера, то можно тогда уж не усложнять, в классе Neuron оставить свойство Type. Если берёте язык C#, используйте его преимущества. Не надо решать задачу на C#, как будто у вас бейсик. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2020, 04:59 |
|
|
start [/forum/topic.php?fid=20&fpage=10&tid=1398548]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
71ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
2ms |
others: | 222ms |
total: | 380ms |
0 / 0 |