Xорошо ли передавать в конструктор класса в качестве параметра this

[mikhailk]

Опасно.
Когда работаешь с событиями, всегда известно, кто тебе отправил событие.
Когда ты раздал ссылку на объект кому попало, не всегда известно, кто именно дернул его методы.
Сугубо имхо.

[Psycho Tiger]

Ещё можно передавать в конструктор super.

new MyClass(super);

Но как-то не читабельно.

new Man(super);

уже неплохо. Но шутками не надо увлекаться.

Если чуть серьезней - то передавать в конструктор this можно. И в этом нет ничего плохого. Но нужно чтобы в приложении была логически четкая иерархия. Мне вот кажется, что парню с именем GlavniiKlass как-то вообще "приказывать" нелогично. А вот попросить его, например, событием - будет вполне нормально.

[Nemez]

Спасибо большое, получил поддержку в дискуссии.

[TanaTiX]

Передавать this... Взять тот же MVC. В этом случае необходимо. Вызов методов родителей - плохая практика. Как правильно заметили, идти на этот шаг нужно осознанно и стараться минимализировать такой подход.

ЗЫ. Котяра, хокку хороша.

[expl]

А вот вызов методов друг друга таким образом как в примере - это, конечно, жуть. Честно говоря, я не могу себе представить ситуации, когда один объект создает другой и разрешает ему себя напрямую дергать...

В паттерне "посетитель" так и делается (правда, тип посетителя при этом интерфейсом обрезается по максимуму). Говорят очень _часто_ применимый паттерн для обработки структуры данных с разными типами элементов. (Правда сам использовал его один раз и в не совсем подходящем случае - поэтому боле сказать ничего не могу)

[mikhailk]

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

[expl]

Да я тоже не особо готов спорить

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

Я часто так делаю. Не вижу ничего дурного.
Допустим есть какой-то большой интерфейс, структуру которого я четко представляю и который не требует особой гибкости. Нужно раскидать все по разным классам для упрощения кода. Вот в такой ситуации я чаще спользую подобные конструкции, чем события.

Да, еще есть паттерн "Медиатор" - там тоже так делают. Впринципе, он делает то же, что подписка на события детей в родителе, но дети больше знают об этом родителе (сцепленность компонентов выше).
Если дети начинают слать кучу событий с параметрами, прося сделать родитель то-то и то-то и чего-то от него ожидая - то, ИМХО, разумнее дать каждому ребенку по ссылке на родителя (можно интерфейсом обрезать, если легче от этого станет) и пусть дергают напрямую.

P.S. На всякий случай, ели юзаешь паттерн - это не значит, что твой код поддерживаемый и расширяемый (Вспомнить хотябы Singleton - куда его GoF только не пихали в своей книге и как он способен осложнить поддержку приложения). Я на паттерны ссылаюсь к тому - что это часто используемые приемы - т.е. народ так делает и часто.

[mikhailk]

Если дети начинают слать кучу событий с параметрами, прося сделать родитель то-то и то-то и чего-то от него ожидая - то, ИМХО, разумнее дать каждому ребенку по ссылке на родителя (можно интерфейсом обрезать, если легче от этого станет) и пусть дергают напрямую.

Подозреваю, вопрос личных предпочтений.
Мне психологически дискомфортно, когда какой-либо объект рулит своим родителем.

Единственно, на мой взгляд, дети шлют не события с параметрами. Дети шлют просто события. А уже родитель решает нужны ему какие дополнительные данные от ребенка, или его можно и так обработать.

[goodguy]

Подозреваю, вопрос личных предпочтений.

Так и есть.

Когда ты раздал ссылку на объект кому попало, не всегда известно, кто именно дернул его методы.

Согласен. В этом единственное неудобство. Но если уж совсем извратиться, то можно еще в качестве параметра передать и того, кто дернул метод, и проверить в родителе )

[mikhailk]

Но если уж совсем извратиться, то можно еще в качестве параметра передать и того, кто дернул метод, и проверить в родителе )

да-да
и обозвать это все паттерном проектирования HappyFamily