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

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

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

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

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

← →
test © (2010-06-17 17:43) [121]

Думкин © (17.06.10 16:43) [118]
Спор то теоретический, код самой функции в 700 строк автор не привел, только пожаловался.

← →
test © (2010-06-17 18:32) [122]

Обсуждение на Потрепаловке:

Автор ветки (пост №1)
Я посрал в лесу, потом вытерся лопухом.

Бывалый (пост №2)
Надо было не лениться взять лопату и закопать.

Несогласный (пост №3)
Гадить в местах общественного пользования аморально!

...

Несогласный 15 (пост №32)
Требования зеленых не просто так, а вдруг медведь наступит!

Оппонент 7 (пост №33)
Вот медведю точно до одного места, он сам так поступает.

...

Бывалый 4 (пост №56)
Ты ГОСТ к верх ногами держишь? Сказано же, хозяйственная постройка должна выступать
в качестве укрытия в случае внезапного артелерийского обстрела. Так что никакого
кафеля, только армированный бетон и стальные балки.

Оппонент 10 (пост №57)
Речь идет про сугубо гражданский объект.

← →
0x00FF00 (2010-06-17 18:36) [123]

> код самой функции в 700 строк автор не привел

А может быть, оно и слава богу?..

> Обсуждение на Потрепаловке:

+1 =)

← →
Rouse_ © (2010-06-17 19:18) [124]

> Mystic © (17.06.10 15:40) [110]
>
> Ну вот, нашел метод на 4380 строк, правка комментарий перед
> методов занимает 3724.

Черд, а я то думал что мои метровые описалова в начале юнита со схемой работы оного сликом обьемны...
ЗЫ: Зотыч - ты был прав :)

← →
Думкин © (2010-06-17 19:23) [125]

> Alx2 © (17.06.10 17:02) [120]
> >Думкин © (17.06.10 16:36) [116]
>
> >А не "увидит ли процедура приватные данные".
>
> Объекты тогда. Вообще, беспредметно пока получается.

Это давно понятно. Битва с моей стороны и шла за уточнение. Но как и все форумное - беспощадно и бесмысленно. Как итог.

-----------

Так как там с функциями и процедурами то!!? :) На 900 строк. И как их сводят к 5 лаконичным строкам методы ООП.

И тишина. :) Все-таки если есть алоритм, то его либо пишут, либо нет. Вот и все. А то абстактности инкапсулированные в голоморфность полимофизма над паттернами обобщенности. А король то голый.

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

> Думкин © (17.06.10 19:23) [125]

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

← →
RWolf © (2010-06-17 20:23) [127]

> ООП поощряет

Поощряет не в том смысле, что «как Буч в умной книжке написал — так и делай»,
а в том, что «хм, а ведь удобно получается, понятно и красиво, и без костылей, и раскидать работу на несколько человек легко».

← →
Jeer © (2010-06-17 20:26) [128]

> RWolf © (17.06.10 20:15) [126]
>
>
> > Думкин © (17.06.10 19:23) [125]
>
> Вообще говоря, речь шла о том, что ООП поощряет использовать
> короткие методы вместо длинных процедур, а не об общем сокращении
> объёма кода.

+1

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

← →
Игорь Шевченко © (2010-06-17 21:08) [129]

RWolf © (17.06.10 20:23) [127]

При хорошей модульности и без ООП можно писать мелкими процедурами и распределяя работу на несколько человек.

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

← →
Думкин © (2010-06-18 05:26) [130]

> RWolf © (17.06.10 20:15) [126]
>
>
> > Думкин © (17.06.10 19:23) [125]
>
> Вообще говоря, речь шла о том, что ООП поощряет использовать
> короткие методы вместо длинных процедур,

Вот именно. Почему же это так, так показано и не было.

← →
Alx2 © (2010-06-18 09:18) [131]

>Думкин © (18.06.10 05:26) [130]

>Вот именно. Почему же это так, так показано и не было.

Да нифига оно не поощеряет. Дает возможность. Дает возможность орагнизовать так, чтобы "среднему" можно было обойтись без поллитра. Дает возможность иерархического "естественного" упорядочивания , делает ближе к "естественному" восприятию. Короче говоря, не более, чем способ организации. Расставил бирки на предметной области "нетак" - короктие методы, "искусственная" компактная организация и апелляции к "а вот говорят" не спасут. Сорри за воз банальностей :)

← →
DiamondShark © (2010-06-18 12:14) [132]

> DVM © (16.06.10 21:25) [13]
> Разбивать ее (например по тем же шагам)
> - это означает делать методы класса, нужды в которых абсолютно
> нет. Никто не будет их вызывать сами по себе (это бессмысленно),
> более того их надо будет вызывать в определенной последовательности,
> что тоже не есть гут, все локальные переменные большой
> функции придется сделать либо полями класса, либо передавать
> в эти методы через параметры (которых будет слишком много),
> что в целом только запутывает того, кто будет читать код.

В паскале есть локальные функции.

← →
euru © (2010-06-18 13:47) [133]

> Alx2 © (18.06.10 09:18) [131]
> Дает возможность иерархического "естественного" упорядочивания,
> делает ближе к "естественному" восприятию.

С чего это вдруг иерархическое упорядочивание - естественное?

← →
Alx2 © (2010-06-18 13:58) [134]

>euru © (18.06.10 13:47) [133]

А с чего неестественное-то? :) Естественно все воспринимать на уровне детализации микробов?

← →
Суслик__ (2010-06-18 14:00) [135]

2автор
от ситуации зависит.
у меня есть такие - не стыжусь.

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

Суслик__ (18.06.10 14:00) [135]

> у меня есть такие - не стыжусь.

У тебя и больше есть, для тестирования компилятора

← →
euru © (2010-06-18 14:50) [137]

> Alx2 © (18.06.10 13:58) [134]
> А с чего неестественное-то? :)

Потому что вводится разработчиком, а не следует из поставленной задачи.

← →
Alx2 © (2010-06-18 14:53) [138]

>euru © (18.06.10 14:50) [137]

Но ведь как раз после анализа предметной области определяется. Т.е. следует из поставленной задачи. Может, я просто недопонял замечания?

← →
Jeer © (2010-06-18 15:18) [139]

> Но ведь как раз после анализа предметной области определяется.

Не все начинают с этого - кому-то дается задание на кодирование и о предметной он ни в зуб ногой.
Считать ли его программистом и считать ли его мнение значимым ?
А таких тут немало. Это не плохо, это просто иной, нижележащий уровень.
Gastarbeiter :)

← →
euru © (2010-06-18 15:46) [140]

> Alx2 © (18.06.10 14:53) [138]
> Но ведь как раз после анализа предметной области определяется.

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

← →
Alx2 © (2010-06-18 15:55) [141]

>euru © (18.06.10 15:46) [140]

Понял. Даже не знаю что ответить. Вот, например, естественный корм дает кошке возможность не сдохнуть с голоду. Подобно тебе я задаю вопрос: "с чего я взял, что корм - естественный? Что если кошек в некотором месте нет вообще?"

На нет - суда нет :)

← →
Jeer © (2010-06-18 15:55) [142]

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

Буквоед ?

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

>euru © (18.06.10 15:46) [140]

То есть я вот к чему:
Конечно, не каждое конкретное "иерархическое упорядочивание" имеет свойство "быть естественным". Но если таковое есть, то его можно заюзать в ООП. Т.е. ООП дает возможность естественного иерархического упорядочивания, о чем я писал в [130].
Но полное отсуствие возможности "иерархического упорядочивания" (для какой-то задачи) автоматом снимает вопрос и о его свойствах. Вот, получилась еще одна банальность.

>Jeer © (18.06.10 15:55) [142]

Кажется, просто идет фикс ощущения, типа: "тут что-то не так - сейчас найду что именно". :)

"ОО-языки упрощают абстракцию, возможно, даже слишком ее упрощают. Они поддерживают
создание структур с большим количеством связующего кода и сложными уровнями.
Это может оказаться полезным в случае, если предметная область является
действительно сложной и требует множества абстракций, и вместе с тем такой
подход может обернуться неприятностями, если программисты реализуют простые
вещи сложными способами, просто потому что им известны эти способы и они умеют
ими пользоваться.
Все ОО-языки несколько сколнны "втягивать" программистов в ловушку избыточной
иерархии. Чрезмерное количество уровней разрушает прозрачность: крайне
затрудняется их просмотр и анализ ментальной модели, которую по существу
реализует код. Всецело нарушаются правила простоты, ясности и прозрачности,
а в результате код наполняется скрытыми ошибкми и создает постоянные проблемы
при сопровождении.
Данная тенденция, вероятно, усугубляется тем, что множество курсов по
программированию преподают громоздкую иерархию как способ удовлетворения
правила представления. С этой точки зрения множество классов приравнивается
к внедрению знаний в данные. Проблема данного подхода заключается в том, что
слишком часто "развитые данные" в связующих уровнях фактически не относятся
у какому-либо естественному объекту в области действия программы -
они предназначены только для связующего уровня.
Одной из причин того, что ОО-языки преуспели в большинстве характерных для них
предметных областей (GUI-интерфейсы, моделирование, графические средства),
возможно, является то, что в этих областях относительно трудно неправильно
определить онтологию типов. Например, в GUI-интерфейсах и графических средствах
присутствует довольно естественное соотвествие между манипулируемыми
визуальными объектами и классами. Если выясняется, что создается большое
количество классов, которые не имеют очевидного соответствия с тем, что
происходит на экране, то, соотвественно, легко заметить, что связующий уровень
стал слишком большим."

к слову пришлось

> Игорь Шевченко © (18.06.10 17:08) [145]

К слову покапайтесь в коде например УПП от 1С. Враз полюбите ООП. Там есть пространство имён, там есть изоляция. Но когда видишь 30-40 идентификаторов в 100 знаков начинается легкий шок. ООП это меньшее зло.

OS/360 без ООП написана.
И никакого зла, только радость :)

Если б у нас столько программеров в кучу собрали было б еще радостнее :)

Наверно, их проблема как раз в том, что с этим у них не было проблем ))

"Проблемы начинаются с мелочей" (С)

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