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

← →
Думкин © (2010-06-17 13:32) [80]

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

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

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

← →
Демо © (2010-06-17 13:36) [81]

Ветвление case из двухсот-трёхсот вариантов не поможет понять, что там, где это необходимо, можно и нужно использовать хоть пять, хоть десять тысяч строк в одной процедуре, а не думать о соответствии шаблонам и догмам, пусть и высказанными признанными авторитетами?

Желание разбить неразделимую процедуру на мелкие подпрограммы - это такой же догматизм, как твёрдолобое отрицание использования GOTO.

← →
Игорь Шевченко © (2010-06-17 13:47) [82]

Marser © (17.06.10 13:09) [74]

Медитируй над словами: "Любую ООП-концепцию можно выразить процедурно без особенных усилий и без особого раздувания кода".

← →
Игорь Шевченко © (2010-06-17 13:48) [83]

Демо © (17.06.10 13:36) [81]

Ну ты ниспровегатель

← →
Демо © (2010-06-17 14:05) [84]

> Игорь Шевченко © (17.06.10 13:48) [83]
> Демо © (17.06.10 13:36) [81] Ну ты ниспровегатель

Да просто принцип такой - всегда думать при следовании советам, оценивать критически, и задавать себе вопросы:
1. Насколько код будет эффективен?
2. Насколько код будет прозрачен и читабелен?

А догматические ограничения - от лукавого.

← →
Kerk © (2010-06-17 14:12) [85]

> Демо © (17.06.10 14:05) [84]
> 2. Насколько код будет прозрачен и читабелен?

Это точно. Какой код более читабелен:
1) Простыня из 10 000 строк
2) Те же 10 000 строк, разбитые на процедуры с описательными именами и параметрами?

← →
Демо © (2010-06-17 14:13) [86]

> 2) Те же 10 000 строк, разбитые на процедуры с описательными
> именами и параметрами?

Я выше привёл пример необходимости такой портянки при необходимости case-ветвления.

← →
Kerk © (2010-06-17 14:14) [87]

> Демо © (17.06.10 14:13) [86]
>
> > 2) Те же 10 000 строк, разбитые на процедуры с описательными
> > именами и параметрами?
>
> Я выше привёл пример необходимости такой портянки при необходимости
> case-ветвления.

Говнокодерский какой-то пример. Кто ж делает 10 тыс ветвлений? Сопровождать ты это как будешь?

← →
BiN © (2010-06-17 14:18) [88]

> Демо © (17.06.10 14:13) [86]
>Я выше привёл пример необходимости
> такой портянки при необходимости case-ветвления.

раздутие кода чаще всего - и в твоем примере, в частности - имеет место при нарушении одного из старинных правил - разделяй код и данные.

не проще ли и не изящнее ли трансформировать такого монстра в итерацию?

← →
Демо © (2010-06-17 14:18) [89]

> Говнокодерский какой-то пример. Кто ж делает 10 тыс ветвлений?
> Сопровождать ты это как будешь?

Почему 10000?
достаточно 300. В каждом ветвлении по 30 строк кода. Вот уже и 10000 строк в процедуре.

← →
Демо © (2010-06-17 14:20) [90]

> > Демо © (17.06.10 14:13) [86]>Я выше привёл пример необходимости
> > такой портянки при необходимости case-ветвления.раздутие
> кода чаще всего - и в твоем примере, в частности - имеет
> место при нарушении одного из старинных правил - разделяй
> код и данные.не проще ли и не изящнее ли трансформировать
> такого монстра в итерацию?

Если сталкивался с протоколом SMPP, то сможешь представить, в каких случаях может возникнуть такая необходимость.

"Итерация" - имеется ввиду Delphi выше v7?

Я, например в D6 пишу.

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

Демо © (17.06.10 14:05) [84]

Ну ниспровергай дальше

← →
Alx2 © (2010-06-17 14:27) [92]

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

← →
BiN © (2010-06-17 14:29) [93]

> Демо © (17.06.10 14:20) [90]
> "Итерация" - имеется
> ввиду Delphi выше v7?Я, например в D6 пишу.

да хоть турбопаскаль.

имелось в виду Alx2 © (17.06.10 14:27) [92]
или подключаемые библиотеки

← →
RWolf © (2010-06-17 14:36) [94]

> Alx2 © (17.06.10 14:27) [92]
> В случае протокола, решаемом кабанским case, я бы завел
> ассоциативный массив методов - всяк метод для своего варианта.
> Вызов через ассоциацию. Имхо, обозримей и сопровождабельней.
>

Я бы даже предложил все варианты сделать классами, производными от абстрактного ответа SMS-центра (или кто там поставляет данные) с переопределёнными методами обработки, а вместо case оставить фабрику классов. Таким образом, разделяем и данные, и код их обработки (и то, и другое заведомо различается для разных ответов).

← →
Демо © (2010-06-17 14:43) [95]

> Игорь Шевченко © (17.06.10 14:25) [91]
> Демо © (17.06.10 14:05) [84] Ну ниспровергай дальше

А зачем ниспровергать? Я просто высказываю своё мнение. Каждый ведь сам за себя решает.

> RWolf © (17.06.10 14:36) [94]
> > Alx2 © (17.06.10 14:27) [92]> В случае протокола, решаемом
> кабанским case, я бы завел > ассоциативный массив методов
> - всяк метод для своего варианта.> Вызов через ассоциацию.
> Имхо, обозримей и сопровождабельней.> Я бы даже предложил
> все варианты сделать классами, производными от абстрактного
> ответа SMS-центра (или кто там поставляет данные) с переопределёнными
> методами обработки, а вместо case оставить фабрику классов.
> Таким образом, разделяем и данные, и код их обработки (и
> то, и другое заведомо различается для разных ответов).

А разве в этом случае код будет более понятен и прост?

← →
Демо © (2010-06-17 14:45) [96]

> Alx2 © (17.06.10 14:27) [92]
> В случае протокола, решаемом кабанским case, я бы завел
> ассоциативный массив методов - всяк метод для своего варианта.
> Вызов через ассоциацию. Имхо, обозримей и сопровождабельней.
>

Вопрос спорный на самом деле.

Что будет проще сопровождать - линейную процедуру или несколько сотен методов.

← →
Kerk © (2010-06-17 14:46) [97]

> Демо © (17.06.10 14:43) [95]
> А разве в этом случае код будет более понятен и прост?

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

← →
Alx2 © (2010-06-17 14:52) [98]

>Демо © (17.06.10 14:45) [96]

>Что будет проще сопровождать - линейную процедуру или несколько сотен методов.

Тут у меня отсыл к авторитетам промышленного программинга. Тот же Макконнелл, Буч и прочая компания. Паттерн, приведенный RWolf [92], родился не от "чтобы этакого написать, чего еще не было?".

← →
Игорь Шевченко © (2010-06-17 14:52) [99]

Alx2 © (17.06.10 14:27) [92]

> В случае протокола, решаемом кабанским case, я бы завел
> ассоциативный массив методов - всяк метод для своего варианта

Поздравляю с изобретением полиморфизма :)

← →
Alx2 © (2010-06-17 14:53) [100]

>Игорь Шевченко © (17.06.10 14:52) [99]

Спасибо :)

В кач-ве отмазки: речь больше именно об участке, где принимается решение "куды бечь".

← →
Демо © (2010-06-17 14:59) [101]

> Alx2 © (17.06.10 14:53) [100]
> >Игорь Шевченко © (17.06.10 14:52) [99]Спасибо :)В кач-
> ве отмазки: речь больше именно об участке, где принимается
> решение "куды бечь".

А как насчёт заполнения кучи параметров для каждого метода?

← →
Демо © (2010-06-17 15:00) [102]

> Kerk © (17.06.10 14:46) [97]
> > Демо © (17.06.10 14:43) [95]> А разве в этом случае
> код будет более понятен и прост?Конечно.И еще не забудь,
> что с пачкой классов может одновременно работать несколько
> человек, а с твоей гигантской процедурой - только ты один.
>

Не надо плодить сущности сверх необходимого.

← →
Alx2 © (2010-06-17 15:02) [103]

>Демо © (17.06.10 14:59) [101]

Куча параметров в методе тоже плохо :) Как вариант - классы-контейнеры в кач-ве параметров.

← →
Игорь Шевченко © (2010-06-17 15:04) [104]

Демо © (17.06.10 15:00) [102]

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

← →
Демо © (2010-06-17 15:06) [105]

> Игорь Шевченко © (17.06.10 15:04) [104]
> Демо © (17.06.10 15:00) [102] Ты путаешь наколенные разработки
> и работу в команде. В наколенных допустимо абсолютно все,
> в команде (обычно) существует набор ограничений для повышения
> совокупной производительности команды в течение жизненного
> цикла приложения.

Тут полностью соглашусь.
Для команды должны быть определены общие требования.

← →
test © (2010-06-17 15:12) [106]

Демо © (17.06.10 15:00) [102]
Бритву Акаму таки опровергли для части случаев.

← →
Jeer © (2010-06-17 15:13) [107]

> Для команды должны быть определены общие требования.

И не членами команды :)

← →
RWolf © (2010-06-17 15:20) [108]

> А как насчёт заполнения кучи параметров для каждого метода?

ТАбстрактныйОбработчик=class private общие поля protected proc Parse(данные);virtual;abstract; //разобрать данные, заполнить поля public constr Create(данные); end; ТОбработчикПакета1=class(ТАбстрактныйОбработчик) private специфичные поля protected proc Parse(данные);override; public constr Create(данные); end; ТОбработчикПакета2=class(ТАбстрактныйОбработчик) ... constr ТАбстрактныйОбработчик.Create(данные); begin Parse(данные); end; proc РазобратьПакет(пакет); var обработчик:TАбстрактныйОбработчик; begin тип:=ВытащитьТипПакета(пакет); данные:=ВытащитьДанные(пакет); case тип of тип1: обработчик:=ТОбработчикПакета1.Create(данные); тип2: обработчик:=ТОбработчикПакета2.Create(данные); ... тип300: обработчик:=ТОбработчикПакета300.Create(данные);

> RWolf © (17.06.10 15:20) [108]

Почему нельзя засунуть тип обработчика в массив из TОбработчикПакетаClass и оттуда доставать по индексу типа? Строк станет в 150 раз меньше.

Ну вот, нашел метод на 4380 строк, правка комментарий перед методов занимает 3724. Так что остается 656 строк + комментарии внутри... Но это все не выглядит очень уж страшным и нечитаемым:
http://mu.webest.net/prog/crafty/main.php

> Фортран уже давно не используется
Еще как используется. Там численные алгоритмы давно и качественно вылизаны

>Mystic © (17.06.10 15:40) [110]

На первый взгляд, повторно выдрать и заюзать решения оттуда в других задачках сложно. Вещь в себе.

> На первый взгляд, повторно выдрать и заюзать решения оттуда
> в других задачках сложно. Вещь в себе.

Это Crafty, движок которые рекомендуется к изучению теми, кто хочет попробовать силы в шахматном программировании. Но выдираются большей частью идеи :)

> Поздравляю с изобретением полиморфизма :)

Ровно так, кейсы метня иногда бесят.

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

А это как раз к теме ближе. А не "увидит ли процедура приватные данные".

> Alx2 © (17.06.10 15:02) [103]
> >Демо © (17.06.10 14:59) [101]
>
> Куча параметров в методе тоже плохо :) Как вариант - классы-
> контейнеры в кач-ве параметров.

Приходим к понятию ссылка.

> Mystic © (17.06.10 15:53) [114]
> Но выдираются большей частью идеи :)

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

> test © (17.06.10 15:12) [106]
> Демо © (17.06.10 15:00) [102]
> Бритву Акаму таки опровергли для части случаев.

Тут решает конкретика. А не факт ОПРВЕРЖЕНИЯ. nfrbt ltkf/

>Думкин © (17.06.10 16:36) [116]

>Приходим к понятию ссылка.

Оно вроде слишком низкоуровневое, чтобы таким путем к нему идти :)

>Думкин © (17.06.10 16:36) [116]

>А не "увидит ли процедура приватные данные".

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

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