Вот, например, есть у моей формы метод:


И Этот метод, допустим, не 5 строчек, а несколько сотен. Таких методов несколько. Если их все оставить в Unit1 - как-то глаза разбегаются, да и метод уже не изменяется, а другие методы меняются - неудобно держать все в одном Unit1. Возникла мысль - поместить его в другой Unit. Например, Unit2. Но как метод класса описать в другом Unit? Или я ерунду придумал?

Это сообщение отредактировал(а) Teleport - 21.8.2009, 10:36

помоему ерунду

если он те мешается напиши в другом юните функцию и вызывай ее в методе
получется что ты перенесеш код в другой юнит но сути это не изменит

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

а) переписать чтобы было несколько(много) методов покороче (рекомендуется)
б) вынести его в inc-файл, а в модуле написать {$I BigMethod.inc}
в) использовать {$REGION}...{$ENDREGION} (хотя поскольку это один метод, фолдинг и так никто не отменял)

В последних версиях среды есть возможность сворачивания кода, тоже вариант если глаза мозолит.

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

Frees, ты сейчас убил весь принцип ООП
Соглашусь с bems тольо по первому пункту, так как остальные не убирают проблему, а маскируют ее

 Не, "приватность" нужна не для того, чтобы "...чтобы публичные методы не разростались;". Зачем новичка вводить в заблуждение?.. Приватность нужна, среди прочего, для сокрытия реализации, для того, чтобы не сообщать пользователю класса лишней, не нужной ему информации. Ну и т.д... См. основы ООП.
И никак не могу согласиться с тем, что вынос функций (не методов!) в отдельный юнит "убивает ООП". Крайне спорное утверждение. А вот вынос метода в другой юнит...  В Дельфи вы это и не сделаете. Если только реализацию метода не делегируете другому классу (о реализации интерфейса я вообще молчу в данном контексте), но это уже немного другое. 
 И по существу вопроса для Teleport:
 1. Юниты бывают большие, от этого никуда не деться, даже при самом грамотном проектировании. Самый лучший наглядный пример, который всегда под рукой: исходники Дельфи, которые вы можете посмотреть сами.
 2. Существует такое "неформальное правило": тело функции (метода, процедуры) должно помещаться на экране, т.е. оно должно быть "обозримым". Если не помещается, то функцию стараются разбить на несколько небольших.
 3. Метод класса в другом юните не опишешь. Можно реализацию метода разбить на "чистые" (pure) функции, и эти функции вынести в другой юнит. Но, сдается мне, пока вам рановато думать об этом.


Это сообщение отредактировал(а) mongoloid - 23.8.2009, 12:07

Если задуматься, косвенно это приводит к одному и тому же. Ты хочешь сказать что публичный метод открывает реализацию? о_О

прежде чем такое говорить, читай то что написано полностью. Он сказал о том чтобы вынести код метода в функцию в другой юнит.
Если бы ты читал все внимательно, то последние три пункта не написал бы, дабы не повторить все, что было уже сказано

2 Keeper89 - про сворачивание знаю.   

2 bems - о твоих способах я не слышал даже. Спасибо, мне будет полезно почитать про него и попробовать в действии.

2 Frees 

- нну да, к такому выводу я тоже пришел.

2 mongoloid -  Спасибо. Буду выносить чистые функции.

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


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

На DK сейчас идёт аналогичное обсуждение.


Нет, это абсолютно правильно. Большие и сложные функции нужно разбивать на несколько более мелких подзадач. Любая книжка по рефакторингу вам ясно объяснит что зачем и почему так ;)

2 CodeMonkey - спасибо. Читаю сижу.
Всем спасибо за помощь. Думаю, что вопрос решен.