Большой проект на Bcb
Народ подскажите, где и что взять почитать про то как лучше/правильнее строить большие проекты?
Добрый день!
Народ подскажите, где и что взять почитать про то как лучше/правильнее строить большие проекты?
А большой это как?
Добрый день!
Народ подскажите, где и что взять почитать про то как лучше/правильнее строить большие проекты?
И в роли кого: проектировщика, аналитика, ведущего программера, начальника отдела?
Начни с Буч'a.
А большой это как?
ну скажем порядка 20 модулей, да это и не важно, понятно что не один модуль.
И в роли кого: проектировщика, аналитика, ведущего программера, начальника отдела?
единственного программера в этом проекте.
Начни с Буч'a.
это что такое? Я вот не знаю.
Проблема с которой столкнулся это организация всего этого дела, а то пока разберусь что где почем и как много времени уходит.
Одно объявлено здесь, другое там, и тому подобные проблемы.
Почитать бы что-нибудь по этому поводу.
если ты один, то надо для себя план составить - где и что будет... главное все обильно комментировать и фиксировать на бумаге или в каком-нибудь редакторе структру программы, базы данных, связи между модулями. тогда и разбираться легче будет...
комментирую много, а хотелось почитать как это народ организует в больших проектах, ведь есть же какая-то систематизация, правила?
может у тебя и получится, а вот у меня на это не хватает терпения - как-то сразу рвусь к программированию: придумал - написал. потом конечно долго приходится разбираться и связи налаживать, но по другому как-то не получается...
есть, но вряд ли ты будешь этим заниматься... по идее перед программированием надо заниматься проектированием и начинать писать программу, когда вся структура будущего детища будет готова и вылизана, когда будут описаны модули, методы взаимодействия между ними, типы данных и т.д. и т.п.
может у тебя и получится, а вот у меня на это не хватает терпения - как-то сразу рвусь к программированию: придумал - написал. потом конечно долго приходится разбираться и связи налаживать, но по другому как-то не получается...
у меня так получается, когда пишу программу под заказ, т.е. заказчик точно знает, что должно получиться в конце, я же продумываю какие функции будут у программы и составляю план, в таком случае все нормально.
но вот сейчас на работе я уже год пишу программу, обновления, версии, там постоянно что-то добавляю, исправляю, и все это накапливается! У меня теперьт даже проблемы с глобальным объявлением функций, пишет предупреждения линкера типа в двух, трех модулях объявлена, так это еще меньшее из бед.
вот посмотри, 57 просмотров топика на данный момент , из них всего трое человек что-то ответили, но пока ничего конструктивного - отсюда следует что проблема актуальна много для кого, но нет решения или тот у кого есть еще ее не прочитал :)
я вот щас задумываю начать большой проект, но чтобы не было неразберизи придумал структуру - один главный модуль, реализующий базовые функции и куча DLL, в которых реализуются специальные функции. но у меня задача позволяет делать такую иерархию, а это не всегда так...
так что при написании программы без четкого плана единственная рекомендация - периодически пересматривать структуру и оптимизировать ее
ну вот, видишь... и у меня та же проблема да и у всех, думаю... одно дело писать под заказ, реализуя четко поставленную задачу и совсем другое создавать что-то свое - это же творчество в чистом виде! садишься за клаву и сам не занешь что именно напишешь - структура программы рождается по ходу, потом по ходу же переделывается, меняется содержиимое классов в соответствии с вновь возникшими требованиями и идеями...
вот посмотри, 57 просмотров топика на данный момент , из них всего трое человек что-то ответили, но пока ничего конструктивного - отсюда следует что проблема актуальна много для кого, но нет решения или тот у кого есть еще ее не прочитал :)
я вот щас задумываю начать большой проект, но чтобы не было неразберизи придумал структуру - один главный модуль, реализующий базовые функции и куча DLL, в которых реализуются специальные функции. но у меня задача позволяет делать такую иерархию, а это не всегда так...
так что при написании программы без четкого плана единственная рекомендация - периодически пересматривать структуру и оптимизировать ее
ну раз такое дело, начну спрашивать конкретнее:
скажем у меня есть 15-20 модулей в программе, они в основном своем независимы, т.е. служат каждый для определенных задач, формы это понятно, а есть свои модули, скажем один для работы с реестром, другой для работы с файлами, и т.д., но есть модули которые содержат такие переменный и функции, которые должны быть доступны из других модулей, сейчас я спрашиваю про правила организации?
на мой взгляд все общие переменные, функции дожны быть в теле основной программы
т.е. ты считаешь что запихать все основное (кстати оно может быть не основным, а доступ к нему из разных модулей нужен будет) в главный модуль и пользоваться, я вот так и делал пока не получился очень большой модуль в котором черт ногу сломит пока найдешь нужную функцию, их куча с хвостиком!
ну раз такое дело, начну спрашивать конкретнее:
скажем у меня есть 15-20 модулей в программе, они в основном своем независимы, т.е. служат каждый для определенных задач, формы это понятно, а есть свои модули, скажем один для работы с реестром, другой для работы с файлами, и т.д., но есть модули которые содержат такие переменный и функции, которые должны быть доступны из других модулей, сейчас я спрашиваю про правила организации?
Я тут реализовал подобную штуку. Правда не на BCB, а Delphi, но большой разницы тут нет, я думаю. Вдохновился одной статьей на Delphikingdom, про интерфейсы. Оказалось, это очень удобная штука. В моем проекте сейчас около 20 различных модулей, в том числе и такие, которые содержат функции используемые и в других модулях тоже. Делается примерно так: главная программа поддерживает некоторый интерфейс, который содержит необходимые функции, позволяющие модулям: встраивать свои меню в главное окно, находить другие загруженные модули и т.п., модули поддерживают другой интерфейс, функции которого: инициализируют модуль, возвращают его имя и т.п. Удобство в том, что не нужно знать конкретного состава как модуля, так и главного приложения, главное взять интерфейс.
У меня есть заставка - SplashScreen, при запуске в ней необходимо проверять много чего (для примера еще и ком порт), т.е. у меня есть функция инициализации com порта (есть он, занят он или нет), так вот эта функция должна работать в форме SplashScreen (при загрузке), в главном модуле программы, а так же еще в некоторых других модулях, чтобы не плодить ее копии запихиваю в главный модуль, но тогда она не доступна в SplashScreen, а если в модуле проекта создавать сначала главную форму а потом показывать SplashScreen, то при значении false функции проверки ком порта вылетает ошибка, т.к. прога должна на отрицательный ответ завершиться?
надеюсь понятно написал :)
Я тут реализовал подобную штуку. Правда не на BCB, а Delphi, но большой разницы тут нет, я думаю. Вдохновился одной статьей на Delphikingdom, про интерфейсы. Оказалось, это очень удобная штука. В моем проекте сейчас около 20 различных модулей, в том числе и такие, которые содержат функции используемые и в других модулях тоже. Делается примерно так: главная программа поддерживает некоторый интерфейс, который содержит необходимые функции, позволяющие модулям: встраивать свои меню в главное окно, находить другие загруженные модули и т.п., модули поддерживают другой интерфейс, функции которого: инициализируют модуль, возвращают его имя и т.п. Удобство в том, что не нужно знать конкретного состава как модуля, так и главного приложения, главное взять интерфейс.
все как-то абстрактно, можно конкретней?
все как-то абстрактно, можно конкретней?
Конкретнее, я думаю, лучше самому разобраться. Незачем мне пересказывать своими словами уже написанное :)
Вот на основе этого делал:
http://www.delphikingdom.ru/asp/viewitem.asp?catalogid=468
т.е. ты считаешь что запихать все основное (кстати оно может быть не основным, а доступ к нему из разных модулей нужен будет) в главный модуль и пользоваться, я вот так и делал пока не получился очень большой модуль в котором черт ногу сломит пока найдешь нужную функцию, их куча с хвостиком!
ну да... просто я ж говорил - моя задача видать немного другая - мне как раз не надо чтобы модули были связаны между собой, а тебе это не подходит.
тогда надо просто нарисовать схему связей модулей друг с другом и ей следовать... больше никак...
а насчет интерфейса модулей - это чисто дельфевая фишка, мне товарищ про нее рассказывал - в подробюности я не вдавался, но он тоже очень хвалил... а я вот не люблю Паскаль :(
а насчет интерфейса модулей - это чисто дельфевая фишка, мне товарищ про нее рассказывал - в подробюности я не вдавался, но он тоже очень хвалил... а я вот не люблю Паскаль :(
В BCB не пробовал, а он разве не поддерживает интерфейсы?
вот совсем просто спрошу Вы мне пожалуйста просто ответьте :) :
есть Модуль 1 в нем функция 1, есть Модуль 2, Модуль 3, из них необходимо обращаться к функции 1, я делаю инклуд в обоих модулях на хидер Модуля 1, все компилиться только линкер варнинг вываливат, типа объявлено в нескольких модулях, что сделать?
а что объявлено? в заголовочных файлах не должно быть объявлений переменных, только прототипы функнций и классы
так я только функции и объявляю?
так я только функции и объявляю?
только прототипы?
только прототипы?
в хидере:
в модуле:
{
// тело функции
}
в хидере:
А в хедере есть директивы предотвращения повторного включения?
#define _ITS_MY_HEADER_
// все содержимое
#endif
Только это, ИМХО, не выход. Тебе придется каждый раз при добавлении нового модуля перестраивать основное приложение.
почему?
ну раз такое дело, начну спрашивать конкретнее:
скажем у меня есть 15-20 модулей в программе, они в основном своем независимы, т.е. служат каждый для определенных задач, формы это понятно, а есть свои модули, скажем один для работы с реестром, другой для работы с файлами, и т.д., но есть модули которые содержат такие переменный и функции, которые должны быть доступны из других модулей, сейчас я спрашиваю про правила организации?
Ламеры делают так:
//in RegEdit.h
//В этом файле собраны переменные, ф-ии и классы отвечающие за...
extern int p1;
...
int funck1();
//in RegEdit.cpp
int p1;
...
int funck1()
{
}
Далее подключаешь модуль к проекту и там где требуется работа с реестром #include "RegEdit.h"
т.е. для меня как непрофессионала работающего только на себе и соответственно выдумывающего структур программы, проблемы не видно, а?
почему?
Ну раз используются H-файлы модулей, значит используются их LIB'ы, и чтобы добавить новый модуль к основному приложению нужно добавить его LIB, а это значит его перестроить надо.
Если же модули подгружаются вручную, например при старте программы делается LoadLibrary, то тогда непонятно как тебе помогает их хедер?
...
а насчет интерфейса модулей - это чисто дельфевая фишка, мне товарищ про нее рассказывал - в подробюности я не вдавался, но он тоже очень хвалил... а я вот не люблю Паскаль :(
а помоему эта фишка носит название - плагины и не зависит от языка прогр. или где?
Ламеры делают так:
//in RegEdit.h
//В этом файле собраны переменные, ф-ии и классы отвечающие за...
extern int p1;
...
int funck1();
//in RegEdit.cpp
int p1;
...
int funck1()
{
}
Далее подключаешь модуль к проекту и там где требуется работа с реестром #include "RegEdit.h"
т.е. для меня как непрофессионала работающего только на себе и соответственно выдумывающего структур программы, проблемы не видно, а?
Давайте разберемся, кто и что имеет ввиду под многомодульным приложением. Если это просто проект, состоящий их многих файлов и в итоге получается один EXE - тогда все OK.
Или автор топика хочет создать приложение, использущее N-ое количество его же DLL, в качестве модулей.
О чем речь-то? Если имеется ввиду первый способ, тогда вообще в чем проблемы?
а насчет интерфейса и плагинов... плагин - это просто подгружаемый модуль, т.е. DLL, а интерфейс в данном случае - это особое понятие языка или среды програмирования
один exe не собирается! есть несколько dll.
Всю информацию можно найти в интернете и на полках магазинов.
Здесь упоминалось, что "перед программированием надо заниматься проектированием и начинать писать программу, когда вся структура будущего детища будет готова и вылизана, когда будут описаны модули, методы взаимодействия между ними, типы данных и т.д. и т.п.".
Действительно, есть такая практика, называемая "водопадом" или "сверху вниз", но время показало, что она неэффективна в большинстве случаев.
Сейчас больше используют итеративный подход. О нем можно почитать в литературе о XP. В кратце же подход выглядит так:
анализируем задачу, оцениваем и планируем первую итерацию, программируем, тестируем, переходим к следующей итерации, где более глубоко анализируем задачу, планируем, оцениваем, программируем и т.д. Для разных задач требуется разное количество итераций. Итеративность подразумевает рефакторинг кода написанного на предыдущем шаге. Тестирование подразумевает использование Unit Test-ов. А вместе это укладывается в практику TDD. Ну а планировать, реализовывать и тестировать проще используя паттерны проектирования.
Поэтому, для создания сложной системы вовсе не обязательно (а даже нежелательно) прорабатывать все нюансы реализации и "вылизывать структуру", в большинстве случаев это будет напрасной тратой времени. Лучше в общих чертах проанализировать задачу, набросать решение, проанализировать ещё раз и набросать более подробное решение и т.д.
Вспомните, как рисуют художники. Они рисуют детали не сразу, а лишь в конце. Перерисовывают некоторые участки неоднократно, не боятся пользоваться стирательной резинкой.
Кстати, обязательно используй в работе системы контроля версий кода, такие как Perforce, StarTeam, CVS, SourceSafe и т.п.
Если действительно есть желание изучать и применять на практике знания по процессу разработки, то рекомендую прочитать про XP (eXtreme Programming - экстремальное программирование), TDD (Test Drive Development - разработка через тестирование), Refactoring (рефакторинг, переработка кода), Designs Patterns (паттерны проектирования).
Всю информацию можно найти в интернете и на полках магазинов.
если не сложно можно название книг, авторов, ссылки, буду признателен :)
вот над этим уже не раз задумывался, может какую-нить посоветуете, какая получше будет, вот я все к CVS склоняюсь?
ну раз такое дело, начну спрашивать конкретнее:
скажем у меня есть 15-20 модулей в программе, они в основном своем независимы, т.е. служат каждый для определенных задач, формы это понятно, а есть свои модули, скажем один для работы с реестром, другой для работы с файлами, и т.д., но есть модули которые содержат такие переменный и функции, которые должны быть доступны из других модулей, сейчас я спрашиваю про правила организации?
Не знаю как на счет правил организации - я обычно переменные которые должны быть видны всем упаковую в закрытые переменные класса - обычно это не класс формы а отдельный, в недрах которого и все происходит, инициализация переменных, получение списка модулей, проверка версий - остальные могут получать если нужно доступ через функции-члены. Удобно и компактно.
Не знаю как на счет правил организации - я обычно переменные которые должны быть видны всем упаковую в закрытые переменные класса - обычно это не класс формы а отдельный, в недрах которого и все происходит, инициализация переменных, получение списка модулей, проверка версий - остальные могут получать если нужно доступ через функции-члены. Удобно и компактно.
был бы очень признателен за небольшой пример, если конечно не сложно.
если не сложно можно название книг, авторов, ссылки, буду признателен :)
СОКРОВИЩА!!!
Книги по XP:
http://www.books.ru/shop/books/27070 (в первую очередь)
эл.вариант:
http://anatolix.naumen.ru/Books/XProgramming?v=wzc
http://www.books.ru/shop/books/82695
http://www.books.ru/shop/books/79190
http://www.books.ru/shop/books/228195
Книга по TDD:
http://www.books.ru/shop/books/121507
эл.вариант:
http://www.natahaus.ru/2005/11/06/print:page,1,ekstremalnoe_programmirovanie__razrabotka_cherez_testirovanie.html
Книга по рефакторингу:
http://www.books.ru/shop/books/30436
эл.вариант:
http://anatolix.naumen.ru/Books/Refactoring?v=17e7
Книги по паттернам проектирования:
http://www.books.ru/shop/books/8451 (в первую очередь)
эл.вариант:
http://anatolix.naumen.ru/Books/DesignPatterns?v=17in
http://www.books.ru/shop/books/29090
эл.вариант:
http://www.books.ru/shop/books/154646 (А.Александреску, доволно сложно)
http://anatolix.naumen.ru/Books/ModernCPPDesign?v=16g9
http://www.books.ru/shop/books/236692 (протиречивые впечатления)
вот над этим уже не раз задумывался, может какую-нить посоветуете, какая получше будет, вот я все к CVS склоняюсь?
В данный момент используем Perforce. Его и советую.
Чисто субъективно, значительно удобнее CVS.
Не знаю как на счет правил организации - я обычно переменные которые должны быть видны всем упаковую в закрытые переменные класса - обычно это не класс формы а отдельный, в недрах которого и все происходит, инициализация переменных, получение списка модулей, проверка версий - остальные могут получать если нужно доступ через функции-члены. Удобно и компактно.
Ну вообще-то это общепринятая архитектура Документ/Вид или Модель/Контроллер/Представление
СОКРОВИЩА!!!
Книги по XP:
http://www.books.ru/shop/books/27070 (в первую очередь)
эл.вариант:
http://anatolix.naumen.ru/Books/XProgramming?v=wzc
http://www.books.ru/shop/books/82695
http://www.books.ru/shop/books/79190
http://www.books.ru/shop/books/228195
Книга по TDD:
http://www.books.ru/shop/books/121507
эл.вариант:
http://www.natahaus.ru/2005/11/06/print:page,1,ekstremalnoe_programmirovanie__razrabotka_cherez_testirovanie.html
Книга по рефакторингу:
http://www.books.ru/shop/books/30436
эл.вариант:
http://anatolix.naumen.ru/Books/Refactoring?v=17e7
Книги по паттернам проектирования:
http://www.books.ru/shop/books/8451 (в первую очередь)
эл.вариант:
http://anatolix.naumen.ru/Books/DesignPatterns?v=17in
http://www.books.ru/shop/books/29090
эл.вариант:
http://www.books.ru/shop/books/154646 (А.Александреску, доволно сложно)
http://anatolix.naumen.ru/Books/ModernCPPDesign?v=16g9
http://www.books.ru/shop/books/236692 (протиречивые впечатления)
В данный момент используем Perforce. Его и советую.
Чисто субъективно, значительно удобнее CVS.
спасибо, обязательно прочитаю.
Глобальные переменные в С++ нельзя объявлять в хидерах! Иначе происходит копирование (пересоздавание) данной переменной при каждом "инклюде" данного хидера.....
Хидер вообще помоему правильно использовать только для обявления прототипов функций, классов и т.п. (т.е. всего того, что само по себе ничего не инициализирует).
Все переменные (а также образцы классов) обявляются в cpp'шках, а доступ к ним из других модулей (т.е. та самая глобальность) реализуется директивой external
т.е. в одном cpp написано допустим
в другом пишем
Это будет означать, что имеется ввиду именно та переменная "а" которая где-то уже объявлена.
Глобальные переменные в С++ нельзя объявлять в хидерах! Иначе происходит копирование (пересоздавание) данной переменной при каждом "инклюде" данного хидера.....
Похоже на то. Создал H-файл, объявил в нем переменную, включил в два СРР-файла, посмотрел, в одном изменил значение, посмотрел опять - второй файл показывает старое значение.
Непонятно только почему адрес переменной и в том и в другом файле один и тот же?
Автор топика спрашивал про организацию серьезного проекта, а не про основы С++.
Что касается глобальных переменных, то лучше вообще без них.