Помогите реструктурировать мой Doc / View более корректно - PullRequest
0 голосов
/ 23 марта 2010

Отредактировано OP.
Моя программа нуждается в большой очистке и реструктуризации.

В другом посте я спросил о том, чтобы покинуть среду MFC DocView и перейти к циклу WinProc & Message Loop (как это называется для краткости?). Ну, в настоящее время я думаю, что я должен очистить то, что у меня есть в Doc View и, возможно, позже преобразовать его в не-MFC, что даже имеет смысл. В моем классе Document сейчас нет ничего полезного.

Я думаю, что начинать нужно с функции InitInstance () (опубликовано ниже).
В этой части:

POSITION pos=pDocTemplate->GetFirstDocPosition();
CLCWDoc *pDoc=(CLCWDoc *)pDocTemplate->GetNextDoc(pos);
ASSERT_VALID(pDoc);
POSITION vpos=pDoc->GetFirstViewPosition();
CChildView *pCV=(CChildView *)pDoc->GetNextView(vpos);

Это кажется странным для меня. У меня только один документ и один вид. Я чувствую, что я иду об этом в обратном направлении с GetNextDoc () и GetNextView (). Пытаться использовать глупую аналогию; Как будто у меня в руке книга, но я должен посмотреть в ее указателе, чтобы выяснить, на какой странице находится название книги. Я устал чувствовать смущение по поводу моего кода. Мне либо нужна коррекция, либо уверенность, либо и то и другое. :)

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

ВСЕ предложения приветствуются!

BOOL CLCWApp::InitInstance()
{
 InitCommonControls();
 if(!AfxOleInit())
  return FALSE;

    // Initialize the Toolbar dll. (Toolbar code by Nikolay Denisov.)
 InitGuiLibDLL(); // NOTE: insert GuiLib.dll into the resource chain

 SetRegistryKey(_T("Real Name Removed"));

 // Register document templates
 CSingleDocTemplate* pDocTemplate;
 pDocTemplate = new CSingleDocTemplate(
  IDR_MAINFRAME,
  RUNTIME_CLASS(CLCWDoc),
  RUNTIME_CLASS(CMainFrame),
  RUNTIME_CLASS(CChildView));
 AddDocTemplate(pDocTemplate);

 // Parse command line for standard shell commands, DDE, file open
 CCmdLineInfo cmdInfo;
 ParseCommandLine(cmdInfo);

 // Dispatch commands specified on the command line
 // The window frame appears on the screen in here.
 if (!ProcessShellCommand(cmdInfo))
 {
  AfxMessageBox("Failure processing Command Line");
  return FALSE;
 }

 POSITION pos=pDocTemplate->GetFirstDocPosition();
 CLCWDoc *pDoc=(CLCWDoc *)pDocTemplate->GetNextDoc(pos);
 ASSERT_VALID(pDoc);
 POSITION vpos=pDoc->GetFirstViewPosition();
 CChildView *pCV=(CChildView *)pDoc->GetNextView(vpos);
 if(!cmdInfo.m_Fn1.IsEmpty() && !cmdInfo.m_Fn2.IsEmpty())
 {
  pCV->OpenF1(cmdInfo.m_Fn1);
  pCV->OpenF2(cmdInfo.m_Fn2);
  pCV->DoCompare(); // Sends a paint message when complete
 }
 // enable file manager drag/drop and DDE Execute open
 m_pMainWnd->DragAcceptFiles(TRUE);

 m_pMainWnd->ShowWindow(SW_SHOWNORMAL);
 m_pMainWnd->UpdateWindow(); // paints the window background

 pCV->bDoSize=true; //Prevent a dozen useless size calculations

 return TRUE;
}

Спасибо

1 Ответ

5 голосов
/ 24 марта 2010

Трудно дать вам хорошие рекомендации, не зная, что должна делать ваша программа.У меня есть только несколько общих замечаний:

  • Ваш InitInstance не выглядит для меня запутанным.Это довольно стандартно с небольшим количеством пользовательского кода.
  • Кроме того, насколько мне известно, уродливая конструкция для извлечения первого представления из класса приложения (цепочка GetDocTemplate -> GetDoc -> GetView) является стандартной.Я на самом деле не знаю другого пути.Вы можете подумать о том, чтобы перенести его в отдельный метод, например CChildView* CLCWApp::GetFirstView(), но это просто косметика, если вам это нужно только в одном месте.

Что вы делаете и какие данные вы размещаетев вашем классе Document и в ваших классах View это больше семантический вопрос, если у вас есть только одно представление.(В любом случае у вас есть только один документ, потому что это приложение SDI.)С технической точки зрения часто возможно и то и другое.Но чтобы быть открытыми (возможно) для более поздних расширений более чем одного представления и следовать стандартному шаблону архитектуры документа / представления, есть несколько практических правил:

  • Данные, которые существуют и имеютто есть независимо от способа их представления и просмотра (файл документа, дескриптор базы данных и т. д.) принадлежат классу документа.Я не знаю, что делает ваш pCV->OpenF1(cmdInfo.m_Fn1) ... and so on, но если это что-то вроде файла, имени файла или параметра, который будет использоваться для доступа к данным любым способом, OpenF1 может быть лучшим методом класса документа.
  • Методы, которые выполняют любые виды обработки или модификации ваших базовых данных, также относятся к классу документа.
  • Данные и методы, которые необходимы только для определенного способа отображения документа, принадлежат к классу представления (длянапример, выбранный шрифт, цвета и т. д.)
  • С другой стороны: если у вас есть фиксированное количество представлений, которые открываются вместе с документом, то может быть неправильно поместить данные представления в документ, особенно еслиВы хотите сделать эти параметры просмотра постоянными.Примером может служить файл с некоторыми статистическими данными - ваш документ - и разделительный фрейм с двумя представлениями: одно отображает данные в виде таблицы сетки, а другое - в виде круговой диаграммы.В таблице есть «данные просмотра», описывающие порядок и ширину столбцов, например, круговая диаграмма содержит данные для настройки цветов круговых частей и расположения легенды.Если вы хотите убедиться, что пользователь получает последнюю конфигурацию вида, отображаемую при открытии файла документа, вы должны где-то сохранить эти параметры вида.По моему мнению, было бы неправильно или неправильно проектировать эти параметры в документе, хранить их и извлекать из любого постоянного хранилища, даже если они нужны только в классах представлений.
  • Если вашПриложение позволяет динамически открывать неограниченное количество представлений для документа, и эти представления являются временными, пока приложение выполняется, и сохранение всех параметров конфигурации представления непосредственно в классах представлений кажется мне более естественным.В противном случае в документе вам потребуется управлять любой динамической структурой данных и установить связь между представлением и записью в этой структуре данных (индекс в массиве или ключ в карте и т. Д.)
  • Если вы сомневаетесь, помещать ли какие-либо данные в класс документа или представления, я бы предпочел документ, потому что у вас всегда есть простой метод доступа GetDocument() в классе View для извлечения членов или вызова методов документа.Для извлечения данных из представления в документ требуется выполнить итерацию по списку представлений.(Помните: Doc-View - это отношение 1-n, даже в приложении SDI.)

Всего несколько центов.

...