Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: to friend or not to friend ?  (Прочитано 7553 раз)
0 Пользователей и 2 Гостей смотрят эту тему.
Tuborg
Команда клуба

ee
Offline Offline

« : 12-09-2007 08:03 » 

Дано:
имеются 2 класса. Class GraphPad, реализующий механизмы вычислений и всякую математику. Есть Class GraphPadDlg, реализующий описание и формирование графического интерфейса соответствующего содержимому GraphPad.

Есть необходимость из метода инициализации класса GraphPad доступиться к методу-protected инициализации диалога OnInitDialog.

Как теперь это красиво сделать? Красиво ли называть их друг-другу friend'ами? Везде в литературе по стилю написания программ говорится что это очень плохо и дискредитирует идею ООП вообще и идею инкапсуляции в частности. Наследовать GraphPad от GraphPadDlg не вижу смысла.... поскольку криво что-то вообще наследовать от ГУИ.
Записан
Scorp__)
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 12-09-2007 09:01 » 

Напишу свое мнение, не претендуя на правильность Улыбаюсь

1. Смысла во friend, в данном случае, я не вижу вообще. Чтобы классы подружить должна быть веская причина, например очень тесная интегрированность этих классов. А интерфейс и логику лучше максимально разделить.

2. Вызывать OnInitDialog ручками по-моему некузяво - это метод-реакция на событие и пусть таким и остается. Для инициализации и изменений есть открытые Create и UpdateData (это под MFC, но для всего остального есть аналоги). Если нужно что-то экзотическое, то лучше написать новый открытый метод (доступ к классу диалогу у тебя есть, иначе все равно friend'a не присобачишь), ну или в крайнем случае открытую обертку для OnInitDialog

3. Самый лучший, на мой взгляд, вариант: добавить в класс графа методы для получения данных и управлять графом и интерфейсом по отдельности из класса приложения или любого другого класса инкапсулирующего их или делегирующего им. В этом случае ты уже абсолютно свободен в выборе интерфейса и можешь диалог переделывать как тебе вздумается, или вообще организовать не Dialog Based интерфейс, при этом совершенно не трогая класс логики.
« Последнее редактирование: 12-09-2007 09:03 от Scorp__) » Записан

- А Вы сами-то верите в привидения?
- Конечно, нет, - ответил лектор и медленно растаял в воздухе.
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #2 : 12-09-2007 11:47 » 

в п.2. полностью поддерживаю Scorp__)

ИМХО это ключевой момент - а нафига это вобще нужно?

Остальные пункты в зависимости от ответа.

Поэтому поподробней в этом месте

Есть необходимость из метода инициализации класса GraphPad доступиться к методу-protected инициализации диалога OnInitDialog.

Лечение зависит от правильности диагноза.
Записан

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Tuborg
Команда клуба

ee
Offline Offline

« Ответ #3 : 12-09-2007 15:26 » new

Scorp__), Спасибо за развёрнутый ответ. Всё вылечилось =)
Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines