Доступ к окнам откуда угодно [C#, WPF]

[pashka_dos]

Только недавно начал изучать C#, WPF. Было много проблем, но они быстро решались. Но эту проблему на могу уже решить второй день. Вопрос, собственно, в заголовке: Как мне получить доступ к дочерним окнам из другого окна (не обязательно главного), например. К главному окну я обращаюсь так:

App.Current.MainWindow

А как наоборот? Как обратиться к дочернему окну? Я почти уверен, что ответ прост до невозможности и лежит на поверхности. Заранее спасибо.

[Selestis]

Самый простой, хотя и нежелательный, способ - завести статические переменные на все нужные окна, и при создании каждого из них заполнитть переменные ссылками на созданные окна.
Например:

class Window1
{
public Window1()
{
Windows.MainWindow = this;
}
}

static class Windows
{
public static Window1 MainWindow;
...
}

Ну это простейший вариант. Если окон определенного типа несколько, то так не прокатит.

[pashka_dos]

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

Самый простой, хотя и нежелательный, способ - завести статические переменные на все нужные окна, и при создании каждого из них заполнитть переменные ссылками на созданные окна.
Например:

class Window1
{
public Window1()
{
Windows.MainWindow = this;
}
}

static class Windows
{
public static Window1 MainWindow;
...
}

Ну это простейший вариант. Если окон определенного типа несколько, то так не прокатит.

Спасибо за ответ. Есть еще варианты? Я слышал это можно сделать с помощью делегатов.

[Selestis]

Ну вариантов вообще не счесть) Что придёт в голову. Просто в большинстве случаев как раз-таки "доступ ко всему откуда угодно" - признак очень плохого дизайна.
Если каждое жалкое окошко будет иметь возможность при смене любой настройки козявить главную форму (например), то такой код очень быстро приведет к появлению фееричных багов.
Как правило, чем меньше объект позволяет делать со своей внутренней логикой - тем лучше.

[pashka_dos]

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

Ну вариантов вообще не счесть) Что придёт в голову. Просто в большинстве случаев как раз-таки "доступ ко всему откуда угодно" - признак очень плохого дизайна.
Если каждое жалкое окошко будет иметь возможность при смене любой настройки козявить главную форму (например), то такой код очень быстро приведет к появлению фееричных багов.
Как правило, чем меньше объект позволяет делать со своей внутренней логикой - тем лучше.

Я, наверное, неправильно выразился) поясню задачу: допустим при нажатии на кнопку на форме Child1, поменять цвет фона на форме Child2 (обе дочерние) так вот, как мне сделать красиво, не нарушая инкапсуляции, и других принципов ООП? Если можно, пример кода, спасибо.

[Selestis]

Как вариант:
делаете интерфейс

interface IColorChanger
{
event Action<Color> ColorChange;
}

пусть форма Child1 его реализует (т.е. там есть такое событие, и оно вызывается при нажатии на кнопку в ней, в параметры идёт цвет.

class Child1 : IColorChanger
{
event Action<Color> IColorChanger.ColorChange; //реализация интерфейса
...
private void someButtonClick(...)
{
if (ColorChange != null)
{
ColorChange(Color.Black);
}
}
}

Пусть у другой формы будет перегруженный конструктор:

class Child2
{
public Child2()
{
//этот конструктор только чтобы работал дизайней форм
}

public Child2(IColorChanger colorChanger)
{
colorChanger.ColorChanged += processColorChanged;
//подписываемся на событие изменения цвета. тут мы не знаем что нам дали форму Child1 - лишь интерфейс, позволяющий узнать о смене цвета
}

private void processColorChanged(Color color)
{
//наш обработчик, который среагирует на смену цвета
BackgroundColor = color;
}
}

class MainForm
{
void do()//некий метод, где создаются дочерние окна
{
var frm1 = new Child1();
var frm2 = new Child2((IColorChanger)frm1);//передаем форме объект для подписки на событие
...
}
}

Разумеется, это только один из вариантов, с использованием механизма событий.

В принципе, если говорить о

не нарушая инкапсуляции, и других принципов ООП

то, если считать нарушением инкапсуляции вызов одной формой метода другой формы, то получается несуразица - типа нельзя тогда вообще ничего явно вызывать ;-)
Главное чтобы просто ответственный за действие был один. Ну или механизм событий, как выше.

Менее труЪ-вариант:

class Child2 : Form
{
//тут метод смены цвета публичный. это вполне нормально, если смена цвета является прямым функционалом этой формы, а не реакцией на глобальное измеенние состояния программы (в таком случае я бы выбрал предыдущий вариант)
public void ChangeColor(Color color)
{
BackgroundColor = color;
}
}

class MainForm
{
private Child2 _frm2;

void do()//некий метод, где создаются дочерние окна
{
var frm1 = new Child1(processColorChanged);
_frm2 = new Child2();
}

private void processColorChanged(Color color)//делегат со ссылкой на этот метод передался другой форме в конструкторе (выше). она его вызовет и инициирует смену цвета, явно производимую здесь
{
_frm2.ChangeColor(color);
}

}

class Child1 : Form
{
private readonly Action<Color> _colorChangeCallback;
public Child1(){}

public Child1(Action<Color> colorChangeCallback)
{
_colorChangeCallback = colorChangeCallback;
}

private void someButtonClick(...)
{
colorChangeCallback(Color.Black);
}
}

Тут по-прежнему ни одна из дочерних форм не знает о другой, однако присутствует явный вызов метода дочерней формы из главной, таким образом она становится чем-то вроде управляющего элемента.

Ну и напоследок: писать в соответствии с принципами ООП не стоит делать самоцелью. Если вы можете эффективно решать задачу, не следуя им, то и не надо. А вот если вы поняли, что эти принципы реально облегчают вам процесс разработки/поддержки/доработки вашей программы, то тогда флаг в руки.

[pashka_dos]

Selestis, спасибо Вам за развернутые ответы, плюсую))

[Luuzuk]

А в сторону PRISM и в частности EventAggregator посмотреть нет желания?