Конференция "Основная" » Разбить .pas-файл одной формы на несколько pas-файлов [D5]
 
  • KSergey © (05.06.18 09:22) [0]
    Есть некий старый проект.
    В нём главная форма - это всё, что есть. Там уже несколько десятков тысяч строк
    И есть обоснованное подозрение, что D5 на таком проекте начинает дурить как при компиляции, так и в отладке.

    Но это всё одна бешенная форма. И это всё её обработчики.

    Вопрос: как бы разбить этот код на несколько pas-файлов?
    Причем include не годится, на сколько я понимаю, всё одно это ж в итоге одна единица компиляции (один .dcu) выйдет.

    Какие тут есть варианты?
  • KSergey © (05.06.18 09:25) [1]
    Мне на ум пришло только вариант с наследованием формы в виде нескольких наследников (без смысла, чисто формально), при этом в каждом из них определить нужную часть кода/обработчиков.
    Но тоже не просто, учитывая, что часть обработчиков для некоторых компонентов на форме можно нечаянно переопределить в потомках.
  • icp © (05.06.18 10:17) [2]
    инклудами например
  • icp © (05.06.18 10:22) [3]
    произвольный кусок паса хоть посредине функции порезанного сохраняем в отдельный файл.
    на месте вырезки вставляем инклуд.
    и так хоть миллиард раз
  • KSergey © (05.06.18 10:37) [4]
    Верно ли я понимаю, что заинклуденные куски будут компиляться отдельно друг от друга?
  • icp © (05.06.18 10:49) [5]
    отдельных дцу не будет.
    для компилера это будет по прежнему одним пасом
  • icp © (05.06.18 10:56) [6]
    кстати а почему дурить будет д5 и не будет xe8 например?
    у обеих нету ни памяти ни частоты.
    это же просто код.
  • Плохиш © (05.06.18 11:14) [7]

    > KSergey ©   (05.06.18 09:22)  

    Насколько я знаю умные слова, это называется "рефакторинг кода".

    PS. Вот не верю я, что логику этих "несколько десятков тысяч строк" нельзя перенести в отдельные модули и вызывать в обработчиках только функции из модулей.
  • KSergey © (05.06.18 11:44) [8]
    Можно, конечно, код обработчиков скопипастить в отдельные модули даже "не вникая", в принципе вариант, конечно.
  • KSergey © (05.06.18 11:45) [9]
    > icp ©   (05.06.18 10:56) [6]
    > кстати а почему дурить будет д5 и не будет xe8 например?

    Я где-то утверждал, что в xe8 не будет?
  • KSergey © (05.06.18 11:45) [10]
    Речь лишь про то, что под этот проект есть D5.
    Про неё и вопрос.
  • Inovet © (05.06.18 11:59) [11]
    > [8] KSergey ©   (05.06.18 11:44)
    > Можно, конечно, код обработчиков скопипастить в отдельные модули даже "не вникая"

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

    А вообще, действительно, компилятору и линкеру дожно быть без разницы какой размер модуля. Не террабайты же там. Наверное что-то тут другое, но не размер.
  • KSergey © (05.06.18 12:29) [12]
    > Inovet ©   (05.06.18 11:59) [11]
    > Если вникать, наверное можно выделить стандартные модули
    > из кучи. Ввод, вывод, расчёт, сохранение данных, загрузка
    > данных, общие утилиты, которые может и не относятся прямо
    > вот только к этой форме. В зависимости от сложности и наличия.
    >  В модулях тоже могут оказаться какие-то куски общего характера,
    >  можно выделить.

    извините, но рука лицо
    Не к вам лично, но как же задолбала эта мода на рефакторинг в индустрии.
    Постоянный рефакторинг ради рефакторинга. Непрекращающйися рефакторинг.
    Самое смешное, что постоянно теряют то тут, то там куски функционала, но первым делом каждый хочет что-нибудь да порефакторить.
  • KSergey © (05.06.18 12:31) [13]
    > Inovet ©   (05.06.18 11:59) [11]
    > А вообще, действительно, компилятору и линкеру дожно быть
    > без разницы какой размер модуля. Не террабайты же там. Наверное что-то тут другое, но не размер.

    Я таки рискну предположить, что именно размер. Ну или количество элементов на форме - тоже вариант.
  • Inovet © (05.06.18 12:40) [14]
    > [12] KSergey ©   (05.06.18 12:29)
    > извините, но рука лицо

    Пардон, но ты же спросил как разбить. Вот так других вариантов нет, если конечно не наугад куски повыкусывать и раскидать по модулям.
  • Inovet © (05.06.18 12:41) [15]
    > [13] KSergey ©   (05.06.18 12:31)
    > Я таки рискну предположить, что именно размер. Ну или количество
    > элементов на форме - тоже вариант.

    Мне первое пришло в голову - посмотреть по тексту изменение опций компиляции. Пример не придумаю на ходу, чтобы глючил.
  • Inovet © (05.06.18 12:46) [16]
    Или, тоже рука лицо, взять этот модуль и начать выкусывать без переноса в другие куски, конечно осмысленно более или менее. Глюк должен пропасть на некотором шаге, начать восстанавливать ранее выкушенные но этот придержать. Глядишь и найдётся проблема.
  • KSergey © (05.06.18 12:47) [17]
    Нет здесь "простого демонстрационного примера".

    Хорошо, таки с живейшим интересом выслушаю идеи по механическому разбиению на чисто формально и технически более мелкие куски.

    > Inovet ©   (05.06.18 12:40) [14]
    > Пардон, но ты же спросил как разбить. Вот так других вариантов
    > нет, если конечно не наугад куски повыкусывать и раскидать по модулям.

    Это всё методы одной формы.
    Отсюда и вопрос как именно раскидать.
    Один вариант был выше предложен: из обработчиков код тупо перенести в функции отдельного модуля.
    Вполне себе вариант.

    Есть ли еще варианты?
  • icp © (05.06.18 13:04) [18]
    вариант выше не предполагает модуля.
    те файлы инклудов не будут самостийными пас модулями. это просто текстовые файлы с кусками кода на паскале
  • KSergey © (05.06.18 13:20) [19]
    > icp ©   (05.06.18 13:04) [18]
    > вариант выше не предполагает модуля.
    > те файлы инклудов не будут самостийными пас модулями.

    Про инклуды уже выяснили, не рассматриваем.
    Я про вариант модулей с вынесенными в них телами обработчиков в виде функций.
  • icp © (05.06.18 13:34) [20]
    и в чем проблема тогда?
    сомнения что так можно?
    так можно
  • KSergey © (05.06.18 13:46) [21]
    Проблемы нет
    Есть внятный вопрос: какие еще возможны варианты?
  • icp © (05.06.18 13:50) [22]
    волшебные?
    штоб ничего не делать и все было?

    есть такой.
    ничего не трогать.
    и не париться что д5 устанет над такими модулями.
  • icp © (05.06.18 13:53) [23]
    навыдумывают вселенских сложностей
    чтобы доблестно преодолевать.
    когда ежу понятно.
    в модуле том говнокод и нужен рефактор.
    но тут же думать надо.
    поетому заменим это идеей фикс.
    разобьем говнокод по говеомодулям и будет карашо сразу.....
  • Плохиш © (05.06.18 15:27) [24]

    > KSergey ©   (05.06.18 12:47) [17]

    > Один вариант был выше предложен: из обработчиков код тупо
    > перенести в функции отдельного модуля.

    Такого варианта выше никто не предлагал.

    > KSergey ©   (05.06.18 12:29) [12]

    > Не к вам лично, но как же задолбала эта мода на рефакторинг
    > в индустрии.

    это проблемы чисто вашей "индустрии".
  • Плохиш © (05.06.18 15:28) [25]
    Согласен с [23]
  • Дмитрий Белькевич © (05.06.18 22:49) [26]
    с чего д5 от 10 тысяч строк опухнет? у меня проект на д7, я так понимаю, почти то же самое , какое-то время вообще D6 было, строк тысяч 200-300 уже был, и ничего не пухло, быстро и шустро работало еще на том железе, что было лет 15 назад. а сейчас то и подавно.
  • Дмитрий Белькевич © (05.06.18 22:53) [27]
    по хорошему - то лучше, конечно, нормально отрефакторить. собсно - разбивка на модули тоже рефактор, хоть может и не такой сильный.
    код у тебя перед глазами, общие рекомендации тут какие тебе дать?
    смотри, что можно выделить во внешние классы, и туда утягивай методы максимально.
    удобно делать с помощью эксперта mmx, он как раз бесплатный недавно стал. я у себя, бывает, переношу между классами методы целиком.
  • Pavia © (06.06.18 20:36) [28]
    D5 очень сильно не любит длинные модули. Вот D7 чуть по лучше там лимит где-то в 2 раза больше.

    А вообще советую перейти на XE там инкрементная сборка. Он обновляет только изменившиеся функции и остальные не трогает.

    Что касается разбиения на модули то тут верно заметили это называется рефакторинг и да тут надо думать. А что-бы функциональность не терять надо тестировать.
  • Германн © (07.06.18 01:54) [29]

    > Pavia ©   (06.06.18 20:36) [28]
    >
    > D5 очень сильно не любит длинные модули.

    Откуда дровишки?
  • KSergey © (07.06.18 07:17) [30]
    > Германн ©   (07.06.18 01:54) [29]
    > Откуда дровишки?

    Из жизни.
    Примерно после 18..28 тыс строчки исходников - часто очень глючит дебаггер (не дебажит) и т.п. проблемы.
    Т.е. проблемы не с компиляцией (хотя и с ней тоже, правда может не объём там причина), а вот с дебагом - беда.

    Модельный пример не просите, его не будет, увы.
  • KSergey © (07.06.18 07:19) [31]
    > Pavia ©   (06.06.18 20:36) [28]
    > D5 очень сильно не любит длинные модули. Вот D7 чуть по лучше там лимит где-то в 2 раза больше.

    Спасибо.
    Приятно осознавать, что не я один такой )
 
Конференция "Основная" » Разбить .pas-файл одной формы на несколько pas-файлов [D5]
Есть новые Нет новых   [92084   +37][b:0.001][p:0.003]