Мастера DELPHI, Delphi programming community Рейтинг@Mail.ru Титульная страница Поиск, карта сайта Написать письмо 
| Новости |
Новости сайта
Поиск |
Поиск по лучшим сайтам о Delphi
FAQ |
Огромная база часто задаваемых вопросов и, конечно же, ответы к ним ;)
Статьи |
Подборка статей на самые разные темы. Все о DELPHI
Книги |
Новинки книжного рынка
Новости VCL
Обзор свежих компонент со всего мира, по-русски!
|
| Форумы
Здесь вы можете задать свой вопрос и наверняка получите ответ
| ЧАТ |
Место для общения :)
Орешник |
Коллекция курьезных вопросов из форумов
KOL и MCK |
KOL и MCK - Компактные программы на Delphi
Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / rsdn.org

 
Чтобы не потерять эту дискуссию, сделайте закладку « предыдущая ветвь | форум | следующая ветвь »

Разбить .pas-файл одной формы на несколько pas-файлов [D5]


KSergey ©   (05.06.18 09:22

Есть некий старый проект.
В нём главная форма - это всё, что есть. Там уже несколько десятков тысяч строк
И есть обоснованное подозрение, что 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 раза больше.

Спасибо.
Приятно осознавать, что не я один такой )


версия для печати

Написать ответ

Ваше имя (регистрация  E-mail 







Разрешается использование тегов форматирования текста:
<b>жирный</b> <i>наклонный</i> <u>подчеркнутый</u>,
а для выделения текста программ, используйте <code> ... </code>
и не забывайте закрывать теги! </b></i></u></code> :)


Наверх

  Рейтинг@Mail.ru     Титульная страница Поиск, карта сайта Написать письмо