Вопрос касается прежде всего форумчан, которые имеют хоть какой-то опыт в написании достаточно больших проектов. Как писать программы, чтобы в дальнейшем их можно было легко усовершенствовать - добавлять возможности. Идеал - для добавления новой функции в прогу, мне нужно написать только ее, без ковыряния в коде. Наверное, для этого надо сначала продумать все процедуры, функции, какие могут понадобится в дальнейшем и занести их в отдельный модуль - secondary, на основе этого модуля уже клепать все что надо. Т.е мы как бы делим разработку программы на этапы - сначала делаем инструменты, а только потом машину. Так? Или тут на помощь приходят объекты?

Объекты - да, они позволяют добавить функцию, при этом нужно знать лишь интерфейс. Это может делать даже другой программист, не автор - исходный код не нуждается в измнениях.
Но только главное условие - это все же голова на плечах и по возможности максимальное продумывание до начала писания кода. Иначе у тебя с объектами получится такая каша, что ты в ней утонешь.
Однозначные рекомендации дать трудно, хотя и возможно. Одно время было очень модно т.н. структурное программирование, которое изучало именно такие вопросы - разработка программы "сверху вниз" и т.п.
Но.. опыт показывает, что серьезную программу все же приходится переписывать, и зачастую не один раз. Не бойся этого.

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

Так что, ООП - тоже не сказка (не думай, что раз начал писать в этой парадигме, то все автоматически получится так, как надо. Не получится... Усилия прилагать везде нужно )

lapp, volvo или volvo, lapp спасибо за ответы!

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

Если идея правильная - потом опишу более детально, как я представляю реализацию всего этого.

P.S чего-то я вспомнил Windows...

Идея правильная, но пока очень общая. Специфика задачи всегда накладывает свои требования и ограничения, а функциональность программы обычно не ограничивается реакцией на события (GUI). Про конкретную же задачу ты пока не обмолвился. Если этот разговор сугубо теоретический, то все же рекомендую почитать на тему "структурного программирования". Это детище Дейкстры, но и Вирт приложил к нему руку. Поищи в сети, наверняка есть что-то в доступном изложении.

Да, ессно, винда (и не только) устроена примерно так. Так что в ней все это уже есть (и доступно в Win32 API), так что можно просто воспользоваться. Но, повторяю, кроме интерфейса у любой проги есть своя функциональность, и главный вопрос в том, как ее организовать.

Это потому что я высказываю только свои мысли, не зная правильны ли они или нет. Да й задачу я подставляю под ООП, а не на оборот, так как хочется разобраться во всем этом.


Спасибо. Буду знать куда копать.



А пример можно...


Тогда как в Винде организована многозадачность?

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

Тут большого разнообразия возможностей нет. В Win3.1 была т.н. пассивная многозадачность, когда процессы как бы сами переключались по кругу. При этом если процесс по какой-то причине не хочет отдать управление или подвиснет - подвиснет вся система. Сейчас используется активная многозадачность, где центральный процесс выделяет всем остальным (в зависимости от приоритета) свой квант времени (о, а не это ли имел в виду Dr.Buggy в Физике? ), то есть грубо говоря несколько процессорных циклов.. Такая система имеет больше накладных расходов по сравнению с пассивной - потому пассивная и была реализована первой: машины были слабее - но зато гораздо более надежная.

Может профи нашего форума будут делиться тем с какими проектными ошибками и подобными трудностями они сталкивались на своей практике??!

Это из разряда "А вот еще был случай.." - да?
Хорошо конечно, но лучше за столом в компании .
Особенностей и трудностей много, только так просто не расскажешь. Будет повод - пожалста..

Ага .

Извините, что запустил тему, но некоторые вопросы остались не решенными.

Не сильно понятно, как СОС будит знать какие объекты существуют. Как мой супер-предок должен давать знать СОС о своем существовании?

Вот я ввел тут свою терминологию, но скорее всего уже существуют уже устоявшийся термины, если да, то прошу поправить.

"Элементарно, Ватсон" (С)...

При создании нового (или, вообще, первого) объекта, куда он добавляется? Правильно, в список (или очередь, как тебе удобнее) ВСЕХ объектов, существующих в системе. А стартовый адрес этого списка (очереди) как раз и хранится в одном из полей СОС... Кстати, чтобы не изобретать свой велосипед полностью, попробуй посмотреть исходники Turbo Vision - очень интересная штука, кстати...

volvo, спасибо . Значит при возникновении какого-нибудь события, СОС запоминает необходимые данные (положения, тип события) и потом сравнивает их с необходимыми полями каждого с существующих объектов и, если находит совпадения, посылает сообщения (записывает в поле) найденному объекту и ...? Как объект узнает, что он активен и что ему надо работать. Или проверка на активность всех объектов проходит каждый раз при возникновении события вмести с сравнениям данных события?


Вот качнул их от http://forum.pascal.net.ru/index.php?showtopic=5119&st=5, что именно надо смотреть?

Ну, например, то, как TVision добавляет окно (это же полноценный объект) к приложению (искать в Хелпе процедуру InsertWindow и вообще все, что касается объекта TProgram)...

Не понял... Если ты выбрал этот объект, то его адрес запоминается в поле ActiveObject твоей СОС... Выберешь новый - поменяешь адрес... Хочешь заморозить активный объект - у тебя есть адрес его экземпляра, в поле объекта IsActive ставишь False...

Понимаешь, пока это чисто теоретически - очень сложно о чем-то говорить, ты бы набросал хотя бы какой-то простенький пример, хотя бы иерархию из 3 уровней объектов, и саму СОС, тогда разговор был бы более предметным...