Эффективная разработка программ: Руководство программиста-практика. Часть 2

ITrader – преобразуй время в деньги!
Программа, дающая доступ к торговле на всех мировых финансовых рынках для возможности заработка с помощью следующих инструментов: валюты, акции, индексы, нефть, драгоценные металлы. Скачай и открой бесплатный Демо-счет! Обучение. Депозит от 1000 рублей.
Подробнее...

Продолжение. Часть первую можно прочитать тут

Статья содержит советы и рекомендации программисту при реализации проекта. Надеюсь, что прочитав статью, вы найдете для себя много нового и полезного. Это является продолжением рассказа о том как быстро, эффективно создать программный продукт!

Модель прикладной области.
Модель прикладной области(МПО) – это класс/иерархия классов, или набор функций собранных в одном логическом месте программного кода, объединенных по какому либо логическому признаку. Задача МПО – максимально точно смоделировать прикладную область и всю логику работы программы в одном месте, для удобства работы/изменения/управления ею.
Суть метода МПО в следующем:
1. Создаем класс МПО с функциями предметной области.
2. Обязательно делаем переменную-член указатель на главное окно.
3. Определяем всю логику программы в функциях класса.
4. Создаем объект МПО в классе главного окна.
5. Вставляем в нужные места класса главного окна, вызовы функций класса МПО.

А теперь подробнее. Рассмотрим следующий пример на С++. Пусть необходимо написать программу – простой текстовый редактор. Ниже указан список задач которые должна решать программа:
1. запись данных в файл.
2. чтение из файла данных.
3. чтение/запись настроек программы.
4. предоставление удобного интерфейса вывода и добавления записей.
5. сервисные функции: поиск, замена.
6. вывод справки и другой информации.

Сначала сделаем класс МПО, назовем его СMyNotebook.
Class CMyNotebook
{
public:
CmyNotebook();
~ CmyNotebook();
int Begin(CMainFrame * pMF);
int End();
int Open();
int Close();
int CreateFile();
int Save();
int LoadOptions();
int SaveOptions();
void DialogHelp();
int Find();
Int m_isChange;
Int m_isOpen;
CString m_PathFile;
OPTIONS m_Options;
CMainFrame * m_pMainFrame;
};

Большинство функций возвращает значение типа int, которое информирует как завершилась функция: удачей(возвратит 1) или неудачей(возвратит 0).
Теперь о каждой функции подробнее.

Begin - функция вызывается при начале работы программы, выполняет подготовительную роль:
- считывание параметров
- загрузка, по желанию пользователя, последнего файла
- инициализация указателя(m_pMainFrame) на главное окно(главный фрейм)

End – функция вызывается при завершении программы, выполняет следующее:
- проверяет сохранен ли файл на диск
- спрашивает подтверждения пользователя о выходе

Open – открытие файла.
Close – закрытие файла
CreateFile – создания файла
Save – сохранение файла
LoadOptions – загрузка опций
SaveOptions – сохранение опций
m_isChange – признак изменения файла, если равен 1, значит изменен иначе не изменен.
m_isOpen – признак открытия файла, если равен 1, значит открыт иначе не открыт
m_PathFile – строка содержит путь к файлу
m_Options – структура содержит все опции программы.
m_pMainFrame – указатель на главное окно

Следующий шаг определение каждой функции. Здесь я не буду описывать каждую функцию, но для примера опишу лишь Begin и End.
int CMyNotebook::Begin(CMainFrame * pMF)
{ // загружаем опции
int answer = LoadOptions();
if (answer == 0 ) return 0;
if (m_Options.m_LastFile != “”)
{// если есть известно имя последнего открытого файла, то открываем его
answer = Open();
if (answer == 0 ) return 0;
}
// инициализируем указатель на главное окно
m_pMainFrame = pMF;
return 1;
}

int CMyNotebook::End()
{
if(m_isChange == 1)
{// если пользователь пытается выйти, а документ при этом не сохранен, то необходимо проинформировать об этом.
CString Text;
Text.Format(“Файл %s был изменен, записать его?”,,m_PathFile)
int answer = m_pMainFrame->MessageBox(Text,”Внимание”, MB_YESNOCANCEL);

if (answer == IDYES)
Save();
If(answer == IDCANCEL)
return 0;
}
SaveOptions();
exit(0);
}

Следующий шаг. Объявите объект МПО в классе CMainFrame.
class CMainFrame : public CFrameWnd
{
…
CMyNotebook m_Notebook; // объект МПО
…
}

Теперь расставте вызовы функций объекта МПО в нужных местах класса CMainFrame, например так:
void CMainFrame::ActivateFrame(int nCmdShow)
{
m_Notebook.Begin(this);
…
}
void CMainFrame::OnDestroy()
{m_Notebook.End();
}
void CMainFrame::OnAppExit()
{
m_Notebook.End();
}

void CMainFrame::OnFileNew()
{
m_Notebook.CreateFile();
}

Преимущества метода МПО на лицо, это:
1. код не дублируется(избежание дублирования кода)
2. вся логика сосредоточена в одном месте
3. широкое поле для расширения и роста без ущерба понятности
Как говорит «монстр» объектно-ориентированного программирования, Гради Буч : «признак хорошо продуманной объектно-ориентированной архитектуры – изменения не разрушают ее, а расширяют, сохраняя существующие механизмы», я думаю это как раз про МПО.
4. Раздел реализации отделен от раздела интерфейса, что дает возможность четко представлять о семантике функций того или иного раздела.
5. Простота и понятность всей архитектуры программы в целом.

Конечно за все эти «удовольствия» надо платить, и платить не чем иным, а временем, которого и так не хватает, даже на простое комментирование кода, но как говорилось ранее(см. Эффективная разработка программ часть 1) «Вложение в комментирование кода окупается многократно» и это очень характерно для МПО.

Стратегия важнее чем тактика. Во время разработки программы, программист решает множество мелких тактических задач, таких как: выделять или нет данных код для повторного использования, что применить : работающий, но непонятный чужой код, или самому написать эту часть. По ходу создания проекта может возникнуть множество «тупиковых» ситуаций, которые вызваны либо технической стороной(пределы языка) или логической (что намного серьезней).
Всегда есть несколько путей решения выхода из тупика:

1 «Временное решение» т.е. решение проблемы с помощью создания каких-либо искусственных условий.
2. Выделение задачи в отдельный класс с целью последующего повторного использования.

Оба этих способа не лишены право на жизнь. Это даже, наверное, скорее всего не альтернативы друг друга, а дополнение друг друга.
И надо не спешить с выбором оных. Если время завершения проекта поджимает (а это в большинстве случаев), то скорее всего лучше использовать первый вариант. А если времени достаточно, тогда применяйте второй способ.

Как этого избежать. Чтобы избежать таких ситуаций, необходимо как можно чаще обозревать проект в целом, т.е. необходимо видеть и лес и каждое дерево. Видеть перспективу развития проекта, т.е. уже с самого начала необходимо знать: какие алгоритмы вам предстоит реализовать, какой способ записи/чтения будет, как справочная система будет интегрироваться в ваше приложение, как программа будет определять рабочий каталог, какие технологии будут задействованы, какие приемущества данного способа решения проблемы и многие, многие другие технические вопросы.
Необходимо подробнейшим образом представлять в деталях создание проекта от начала до конца, лучший вариант – ведение «Проектного документа»(Design document), где все разложено «по полочкам» (подробнее об этом – «Эффективная разработка программ ч. 1»)
Все тактические решения в ходе работы создания программы, должны поддерживать главные стратегические направления, и если это так - проект обречен на успех!

Многоликий результат. При планировании проекта, сделайте не один конечный результат, а несколько. Конечные результаты эти пусть отличаются от друг друга незначительно, один например не включает в себя каких то дополнительных функций, другой имеет более простой интерфейс, третий не имеет контекстной справки и т.д. Например, для простого текстового редакторы конечные результаты могут быть такими:

1. Основные функции + Красивый интерфейс + поиск/замена
2. Основные функции + Классический интерфейс
3. Основные функции + поиск/замена
…

Что это дает? Это дает гарантию, что проект вообще будет завершен. Например в конце разработки проекта, один из классов отвечающих за интерфейс отказывается работать – разработчик при этом, не тратя времени и сил на ликвидацию проблемы, просто переключается на версию проекта, где этот класс не требуется. А по завершению проекта можно разобраться в чем было дело.

При планировании различных вариантов программы с разными наборами функций, вам станет ясно какие функции действительно нужны, а какие можно и не включать(или оставить для будущих версий программы).

Итак, теперь вы пополнили свою копилку знаний еще несколькими советами и рекомендациями по разработке ПО. Автор надеется, что эти знания будут востребованы и окажут вам неоценимую услугу в увлекательном и интересном деле – разработке программ!

Успехов!
Замечания и предложения прошу направлять на: abhome@atnet.ru