Общий вопрос: как проектировать программу под Win32?

Тема в разделе "WASM.WIN32", создана пользователем Oleg_SK, 7 дек 2004.

  1. Oleg_SK

    Oleg_SK Guest

    Публикаций:
    0
    Привет всем!

    Довольно часто можно услышать утверждение, что какая-то программа плохо спроектирована. Хочу задать Вам ламерский вопрос: как проектируются программы под Win32? У меня в этом плане серьезный недостаток в знаниях. А ведь мне хотелось бы не держать все устройство программы в памяти, а иметь схему программы, чтобы в случае необходимости можно было увидеть, на что повлияет изменение в одном месте программы. Да и в том случае, если я вернусь к разработке программы после некоторого перерыва (уже забыв ее устройство), мне гораздо проще было бы войти в работу, изучив ее схему, чем, изучая ее код. Единственная статья, которую я когда-то читал по этой теме, была опубликована в ZX-Ревю'92 (был когда-то такой журнал) в рубрике "Профессиональный подход". Там было описано нисходящее проектирование программы с построением блок-схемы программы. Этот метод еще можно применить при проектировании программ для MS-DOS (ну, и кое-где, под Win32). Но у меня не получается применить этот метод проектирования, в Win32. Например, не получается с его помощью описать взаимодействие между потоками или даже просто между обработчиками разных сообщений в оконной процедуре. Приходится держать все в памяти, а это, IMHO, не серьезно. В общем, что вы мне посоветуете? Что можно почитать по этой теме?
     
  2. Edmond

    Edmond узник замка IF THEN ELSE

    Публикаций:
    0
    Регистрация:
    2 сен 2002
    Сообщения:
    203
    Адрес:
    WASM.RU
    Oleg_SK



    Это слишком общий вопрос.



    Проектирование под Win32 как само проектирование - слишком специфично.



    Что касается Общего проектирования, то как обычно:



    1. Распределение вида ресурсов определённого вида ведёться одним кодом (который часто носит название ядра или сервера)

    2. Множество элементов одного вида называют классом, а сами элементы объектами (ООП)

    3. Подсистема обработки ошибок обычно имеет 3 уровня: пользовательский системный, и критический.

    4. UI проектируется максимально отделённо от самих компонентов... возможны различные схемы.

    5. Компонентный подход неплохо идёт. (имееться ввиду не COM, а сам подход)



    Что почитать.... Книги есть. Но как бы все они написаны с точки зрения "разговора чашки за чаем"...



    А вот обучение - нет такой не видел.
     
  3. Edmond

    Edmond узник замка IF THEN ELSE

    Публикаций:
    0
    Регистрация:
    2 сен 2002
    Сообщения:
    203
    Адрес:
    WASM.RU
    Oleg_SK

    Как это не странно звучит - уменьшение объёма кода защёт создания универсальных подсистем РУЛИТ!!!!



    Оптимизация по скорости встречаеться редко.
     
  4. NoName

    NoName New Member

    Публикаций:
    0
    Регистрация:
    1 авг 2004
    Сообщения:
    1.229
    Вопрос между прочем очень актуальный. Практически каждый начинающий программер или кодер спотыкаются об это. Например однажды мне нужно было написать мультитредную программу юзающую сокеты в очень извращенном виде, но сами понимаете блокнот не "трехмерный", пришлось обходится своим мозгом.



    Скорее всего где-то в инете есть фирма уже создавшая софт, который позволят проектировать средние и большие программы. Но такой программы чтоб она была небольшого размера и со здоровой функциональностью я не встречал. Если кто найдет, то пж-та скажите мне.
     
  5. Oleg_SK

    Oleg_SK Guest

    Публикаций:
    0
    NoName



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



    Edmond

    Спасибо.
     
  6. S_T_A_S_

    S_T_A_S_ New Member

    Публикаций:
    0
    Регистрация:
    27 окт 2003
    Сообщения:
    1.754
    Oleg_SK >




    IMHO для правильного ответа на этот вопрос нет необходимости вообще хоть как-то разбираться в программировании. Нужно просто знать что хочет услышать "работодатель":







    Не совсем по вопросу проектирования (а что это ? =))), но думаю будет полезно:

    Ален Голуб "ВЕРЕВКА ДОСТАТОЧНОЙ ДЛИНЫ, ЧТОБЫ… ВЫСТРЕЛИТЬ СЕБЕ В НОГУ" (Alen I. Holub. "Enough Rope to Shoot Yourself in the Foot.") -

    Эдвард Йордан "Смертельный марш" (Edward Yourdon "Death March")



    ЗЫ: А какой номер ZX-Ревю'92 ?
     
  7. Oleg_SK

    Oleg_SK Guest

    Публикаций:
    0
    S_T_A_S_

    Я похоже ошибся. Журнал, на самом деле, не за 1992г., а, похоже, за 1991г. Номера не знаю, т.к. у меня распечатка.
     
  8. Monk

    Monk New Member

    Публикаций:
    0
    Регистрация:
    14 июн 2008
    Сообщения:
    1
    Хотя тема очень старая, я все-таки мимо пройти не смог. =) Проектирование программ штука действительно важная. Без проектирования можно писать разве что небольшие программки.И хотя программисты в одиночку пишут либо маленькие либо средние программы, умение проектировать может облегчить жизнь и сэкономить время. Есть книги по технологии программирования - их стоит почитать. Вот книги которые бы я порекомендовал посмотреть Совершенный код. Стива Макконелла - можно найти тут - http://infanata.org, и тут - http://torrents.ru. Иванова С.Г. Технология программирования - http://infanata.org, Этот сайт тоже стоит посмотреть - http://rusdoc.ru, раздел - Управление проектами.
     
  9. masm32

    masm32 New Member

    Публикаций:
    0
    Регистрация:
    26 фев 2008
    Сообщения:
    147
    Может быть имеется ввиду "проектирование интерфейсов" ? - это отдельная сущность, не связанная с совершенством кода или методиками управления проектами.

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

    z0mailbox z0

    Публикаций:
    0
    Регистрация:
    3 фев 2005
    Сообщения:
    635
    Адрес:
    Russia СПБ
    masm32
    Плохо спроектированный интерфейс способен довести до истерики, точно :)
    Но это с ТЗ юзера
    В топике видимо речь идет о ТЗ кодера, то есть плохо спроектированная программа - это такая про которую говорят - "да, неплохо бы добавить то-то и то-то, но трогать страшно"

    Когда программа пишется у кодера в башке создаются всякие сложные замысловатые неочевидные конструкции с помощью которых он понимает алгоритмы и сценарии работы программы. Потом эти конструкции в башке исчезают, начинается новый проект, а программа остается. И если то что было в башке не выражено ясно и просто в исходнике - всё-приехали, другому кодеру легче заново переписать.

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

    С практической ТЗ - для того чтобы себя не материть впоследствии - не ленитесь пишите больше всякой отладочной фигни, логгеры, чекеры, думперы, вспомогательные утилиты - чем больше их, тем опытнее программист.
     
  11. AsmGuru62

    AsmGuru62 Member

    Публикаций:
    0
    Регистрация:
    12 сен 2002
    Сообщения:
    689
    Адрес:
    Toronto
    Разбить на более простые куски (кстати, почему невозможно?) - в этом и есть разрешение проблемы. Объектно-ориентированный подход, но такой при котором "куски" (или классы) можно переносить из проекта в проект.
     
  12. W4FhLF

    W4FhLF New Member

    Публикаций:
    0
    Регистрация:
    3 дек 2006
    Сообщения:
    1.050
    Monk

    Это книга к проектированию и системному анализу не имеет практически никакого отношения(за итскючением одной главы), она затрагивает в основном аспекты реализации.

    По проектированию читайте Г. Буча и К. Пармана, это уже классика.

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

    Для небольшого проекта, примерно до 5-6 тыс. строк, мне хватает простой диаграммы нарисованной на бумаге, главное выделить правильно основные независимые сущности, на них уже нанизывается весь остальной функционал без особых проблем. Здесь часто бывают полезны шаблоны проектирования.

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

    Вот кстати последним знаменитым примером, который показывает результат пренебрежительного отношению к проектированию, либо вообще отсутствие этого этапа, является QIP 2005(не путать с QIP Infum). Кто не в курсе, автор прекратил его разработку как раз потому, что полученный объём кода уже не поддавался дальнейшему развитию и расширению, о чём автор и заявил:

     
  13. wasm_test

    wasm_test wasm test user

    Публикаций:
    0
    Регистрация:
    24 ноя 2006
    Сообщения:
    5.582
    Однако, к сожалению, стабильностью там еще и не пахнет.. По сравнению с 2005..
     
  14. z0mailbox

    z0mailbox z0

    Публикаций:
    0
    Регистрация:
    3 фев 2005
    Сообщения:
    635
    Адрес:
    Russia СПБ
    AsmGuru62
    В каких-то случаях это работает, кстати и без всякого ООП. Просто есть такие куски кода которые с минимальными переделками можно таскать из проекта в проект. Но большинство кода в проекте все же уникально.
     
  15. jhons

    jhons New Member

    Публикаций:
    0
    Регистрация:
    23 ноя 2007
    Сообщения:
    26
    банально. любая програмка в винде (приложение) - это набор процессов, оные суть - ловцы сообщений системы (если програмка с окошками - опрос сообщений системы и засылку их себе проводишь ручками).
    типа за классы (ООП) просто куча удобных (самолепных) структур и подпрограмок для работы с оными в виде разнообразных inc-ов с шарами на внешнии функции апосля включаемых библиотек... хотя даж проще тупо с кодом сих "классов".
     
  16. halyavin

    halyavin New Member

    Публикаций:
    0
    Регистрация:
    13 май 2005
    Сообщения:
    252
    Адрес:
    Russia
    Начните участвовать в development и design соревнованиях на topcoder.com, и вы поймете как проектируются программы.