функции и процедуры

← →
Сменил ник (2010-06-17 01:16) [40]

Демо © (17.06.10 01:13) [39]

> Меня-то как раз мои процедуры вполне устраивают.

Вот и славно

> Наверное умный мужик?

Не дурак. Почитай

> Странная сентенция по поводу 7 лет.
> К чему бы это?

А я видел твои творения

← →
Демо © (2010-06-17 01:35) [41]

> А я видел твои творения

Какие такие творения?

← →
Германн © (2010-06-17 01:38) [42]

> Это твои процедуры неудобны для сопровождения.

Пардон, что вмешиваюсь. Но такое утверждение следует обосновать. Хотя бы личным опытом сопровождения.

← →
Дмитрий Белькевич (2010-06-17 02:03) [43]

>Стремиться все разбить на функции в 5-10 строчек как и все обернуть классами, суть которых класс ради класса - вот это ненормально, это паранойя.

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

← →
test © (2010-06-17 02:04) [44]

Сейчас про какой язык речь идет? Для SQL это в порядке вещей сплошь и рядом и ничего.

← →
Marser © (2010-06-17 02:08) [45]

> В школу! (16.06.10 23:16) [25]
>
> Jeer © (16.06.10 22:58) [23]
>
> Метод сильно отличается от процедуры ?

Бугага! Да всем он отличается от процедуры. Принадлежность к классу даёт ему доступ к остальной функциональности самого класса и его предков, не говоря уже о полях класса.
Если у человека в голове не опилки, если он умеет разбить крупную задачу на кванты подзадач, если он понимает значение и мощь трёх китов ООП (иногда выделяют разделение доступа как четвёртый), то он не пишет линейный процедурный код в классах, он создаёт гибкую расширяемую классовую иерархию (возможно, и с интерфейсами) и метод на 1000 строк у него не появится в принципе.

← →
Marser © (2010-06-17 02:10) [46]

> Rouse_ © (16.06.10 23:56) [36]
>
> Кстати, открою маленький секрет - достаточное количество
> NtАпи функций реализованы блобами в более чем 1000 строк.
> Ну это так... о птичках :)

Это если пишется один раз и навека. А если... Помилуй, Господи, нас, грешных...

← →
Думкин © (2010-06-17 05:52) [47]

> Но исключение только подтверждает правило.

Ежа и ты туда же. В такой постановке фраза сия глупость есть. Смысл в ней другой. И изначально также было. Но прижилось вот такое вот понимание. Как такое произносить то можно, тем более программисту? Не стыдно?

← →
Rouse_ © (2010-06-17 10:19) [48]

> Marser © (17.06.10 02:10) [46]
> Это если пишется один раз и навека

Ну судя по каментариям в этих функциям - переписывалось там все минимум несколько раз, так что ой :)

← →
Игорь Шевченко © (2010-06-17 10:51) [49]

Marser © (17.06.10 02:08) [45]

> Да всем он отличается от процедуры. Принадлежность к классу
> даёт ему доступ к остальной функциональности самого класса
> и его предков, не говоря уже о полях класса.

Не отличается...Вот такая фигня. Так что ты бугагу прикрой слегка, чтобы в луже не сидеть

← →
RWolf © (2010-06-17 11:02) [50]

> Игорь Шевченко © (17.06.10 10:51) [49]

Наследование и интерфейсы — всё же весьма значимое отличие, надо сказать.

← →
Игорь Шевченко © (2010-06-17 11:44) [51]

RWolf © (17.06.10 11:02) [50]

> Наследование и интерфейсы — всё же весьма значимое отличие,
> надо сказать.

В контексте размера в строках - офигительно значимое.

← →
Marser © (2010-06-17 11:59) [52]

> Игорь Шевченко © (17.06.10 10:51) [49]
>
> Marser © (17.06.10 02:08) [45]
>
>
> > Да всем он отличается от процедуры. Принадлежность к классу
> > даёт ему доступ к остальной функциональности самого класса
> > и его предков, не говоря уже о полях класса.
>
>
> Не отличается...Вот такая фигня. Так что ты бугагу прикрой
> слегка, чтобы в луже не сидеть

О, расскажите-ка мне о доступе к приватным полям и методам класса из не зависящей от него процедуры (RTTI и прочие рефлексии не предлагать)
Или сами бугагу прикройте, чтобы в луже не сидеть, или речи свои мудрые подфильтровуйте.

← →
Jeer © (2010-06-17 12:02) [53]

> офигительно значимое.
>

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

← →
Marser © (2010-06-17 12:02) [54]

> Игорь Шевченко © (17.06.10 11:44) [51]
>
> RWolf © (17.06.10 11:02) [50]
>
>
> > Наследование и интерфейсы — всё же весьма значимое отличие,
>
> > надо сказать.
>
>
> В контексте размера в строках - офигительно значимое.

Игорь, вы, может, не в курсе, но ООП это не значит запихнуть весь процедурный код в класс. Божественный метод является антипаттерном, равно как и божественный класс, потому что в рамках ООП есть очевидные и удобные средства для разведения отдельных фрагментов функциональности на разные уровни абстракции.

← →
Ega23 © (2010-06-17 12:06) [55]

> О, расскажите-ка мне о доступе к приватным полям и методам
> класса из не зависящей от него процедуры

type TMyObj = class (TObject) private FBar: string; public procedure Foo; end; procedure TMyObj.Foo; begin ShowMessage(FBar); end; procedure MyProc; var obj: TMyObj; begin obj := TMyObject.Create; try obj.FBar := "Bar"; obj.Foo; finally obj.Free; end; end;

Ты эта... Аккуратнее... :)

← →
Jeer © (2010-06-17 12:11) [56]

А вообще я уже посоветовал выше провести стат.анализ над несколькими общеизвестными библиотеками - закономерности-то и проявятся :)

То, что какой-то конкретный гений "нарисует" процедуру на 5 тыщ строк - бог в помощь ему.

← →
Marser © (2010-06-17 12:15) [57]

> Ты эта... Аккуратнее... :)

Олег, я понимаю это как приглашение к флуду, но костыль внутри класса обратно не в счёт.
А ИШ мало того, что обгадил меня походя, так ещё и вызвал у меня разрыв шаблона... Вроде Гуру и Учитель (мой в т.ч.), а связи между правильным применением ООП и компактностью и читабельностью кода не видит...

← →
Правильный$Вася (2010-06-17 12:16) [58]

> Ты эта... Аккуратнее... :)

некошерный пример, скорее исключение

← →
Ega23 © (2010-06-17 12:18) [59]

> некошерный пример, скорее исключение

читай DB.pas, там этих "исключений" есть и много.

← →
Игорь Шевченко © (2010-06-17 12:25) [60]

Marser © (17.06.10 12:15) [57]

> О, расскажите-ка мне о доступе к приватным полям и методам
> класса из не зависящей от него процедуры

А скажи мне, на кой хрен процедуре доступаться к приватным полям ?

← →
Игорь Шевченко © (2010-06-17 12:25) [61]

Marser © (17.06.10 12:15) [57]

> А ИШ мало того, что обгадил меня походя

обтекай

← →
Jeer © (2010-06-17 12:27) [62]

Ну вот, сам предложил, сам и сделал ( это я о себе )

Анализ 5 модулей (cDataStruct, cFileUtils, cStreams, cStrings, cUtils) из немаленькой библиотеки Давида Батлера ( Delphi Fundamentals ) дает такие предельные числа строк кода (LOC), соответственно по модулям:39,80,73,124,59.
Это и процедуры и методы.
В основном же, число строк на P или PM значительно меньше.

P.S.
Анализ выполнен с помощью Peganza Pascal Analyzer v.4.6.0

← →
Jeer © (2010-06-17 12:33) [63]

Берем SynEdit.pas
Таки нашелся основной метод ExecuteCommand на 691 LOC :)
Это, скорее исключение, т.к. все остальные не превосходят 140 LOC

← →
Marser © (2010-06-17 12:37) [64]

>
> Игорь Шевченко © (17.06.10 12:25) [60]
>
> Marser © (17.06.10 12:15) [57]
>
>
> > О, расскажите-ка мне о доступе к приватным полям и методам
> > класса из не зависящей от него процедуры
>
>
> А скажи мне, на кой хрен процедуре доступаться к приватным
> полям ?

Хе :)
Вот вы и сами подошли к ответу :)
Неудобно из лука пулями стрелять, да? ;-)
Метод и процедура отличаются тем, что применяются в принципиально разных концепциях программирования.

> обтекай

Да пофик, на самом деле. Меня, было дело, в инете обкладывали так, как вы, арбатский интеллигент, просто не умеете ;-)

← →
Jeer © (2010-06-17 12:40) [65]

Берем исходник от DBISAM ( Elevate Software СУБД )
Наибольший LOC = 429 в методе RestructureTable
Остальные в диапазоне 10..200

← →
Игорь Шевченко © (2010-06-17 12:44) [66]

Marser © (17.06.10 12:37) [64]

> Метод и процедура отличаются тем, что применяются в принципиально
> разных концепциях программирования.

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

Любую концепцию ООП можно реализовать процедурно (и наоборот).

← →
Jeer © (2010-06-17 12:46) [67]

Берем громадный модуль FastGeo и имеем LOC=92 для метода InterSectionPoint, все остальное значительно меньше.

Ну вот, собственно примерно и понятно, как обстоит дело с размерами P и PM.

← →
Ega23 © (2010-06-17 12:46) [68]

Драма зачот

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

Мне вот нужно решить систему линейных уравнений. Где будет принципиальное различие с выходом на длину процедур-методов при реализации?

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

Есть процедуры(*методы, функции*) которые требуют определенного размера, например обработка очереди сообщений если обрабатывать все сообщения или приличную часть то в там один case может и на 700 вылезти и на тысячу, другая крайность когда все до одной двух операций разнесено по методам, функциям, процедурам тоже не сильно нормальный вариант. Может как то золотой середины держаться? Если нужна длинная функция то она пишется, размер сам по себе ни о чем не говорит.

> меньше, чем выполнить эту реализацию чисто на процедурном
> подходе.
> Полагаю, что так.

Почему? В чем разница, чтобы не уложиться в те же строки при процедурном подходе?

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

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

Слуга покорный. Читабельность линейного кода такого плана можно, конечно, повысить, с умом применив модульность, например, но всё равно это плосковато. Проверено на примере исходников и плагинов WireShark, писаных на ANSI C.

> Думкин © (17.06.10 12:52) [69]
>
>
> > потому что в рамках ООП есть очевидные и удобные средства
> > для разведения отдельных фрагментов функциональности на
> > разные уровни абстракции.
>
> Мне вот нужно решить систему линейных уравнений. Где будет
> принципиальное различие с выходом на длину процедур-методов
> при реализации?

Речь кагбэ о задачах, требующих тысячу строк кода.

> Jeer © (17.06.10 13:06) [73]

Ну грубо так переход можно таким образом:

1. Данные класса в record.
2. Методы класса в процедуры с передачей дополнительно параметром "хозяина".

Какие процедуры при этом могут вырасти? Видимо, я чего-то упускаю.

> Речь кагбэ о задачах, требующих тысячу строк кода.

и че? Где та разница в реализации по строкам кода?

← →
Вариант (2010-06-17 13:16) [78]

> Думкин © (17.06.10 13:11) [76]

> 1. Данные класса в record.
> 2. Методы класса в процедуры с передачей дополнительно параметром
> "хозяина".

Это ООП в стиле ADA95, там именно так - "хозяин" передается явным параметром:-)

> Думкин © (17.06.10 13:12) [77]
>
>
> > Речь кагбэ о задачах, требующих тысячу строк кода.
>
> и че? Где та разница в реализации по строкам кода?

Речь шла о сложных и объёмных задачах, это ты затронул тему отстрела зябликов из зенитных орудий.

> Marser © (17.06.10 13:28) [79]

Видимо, явсе-таки тупой. Но разница то где? Зяблики, незяблики, гомадрилы, вараны - разница то где в числе строк? Именно про то, что в сабже, а не про трудности сопровождения.

Т.к. ты видимо, только и делаешь, что не по зябликам стреляешь, то я думаю, что тебе не сотсавит труда привести пример ООП-ной реализации, которая будучи переведена в процедурное значительно увеличит число строк.

функции и процедуры Найти похожие ветки