ООП vs структурное прогр. vs функциональное прогр.

[GM]

Какая концепция вам больше нравиться?
ЗЫ: Возможно я ошибаюсь в терминах, так что поправьте меня, если что-то не то.

[tyomitch]

Lambda calculus рулит, потому что я в нём ничерта не понимаю

[Денис Победря]

Мне нравится .Нет, ПауерБейсик, АСМ. И за что голосовать?

[Ramzes]

За што хочешь ))))

ООП ибо рульно

[BV]

Мне все одинаково нравится. В конце концов, выбор зависит от задачи.

[MeMBus]

Стока много слов незнакомых, одно ООП чего стоит

[tyomitch]

ух ты. Все, кроме меня, единогласно за ООП.
Если мотивировка у них такая же, как у меня -- тогда забавно

[--=GAMER=--]

А чё такое ООП????

[Tamplier]

НЛП

[GAGArin]

Tamplier
Да НЛП рулит над другими однозначно ))

[Oxygen]

А чё такое ООП????

Гы. Объектно Ориентированное Программирование.

[Денис Победря]

А вроде бы не функциональное, а процедурное

[hCORe]

Вот, как всегда ни черта не знаю по теории. Не могу отличить структурное программирование от декларативного, а декларативное - от процедурного. Не знаю наизусть закон де Моргана. И уравнение Кортевега-де Фриса (хотя это уже из физики.) Что не мешает писать всякие ListControl'ы, HTML-редакторы и утилиты.

Функциональное - это совсем другое. Лисп, например. Очень, говорят, подходит для обработки (парсинга) текстов.

[tyomitch]

Структурное = Процедурное = Декларативное. Типа кубэйсика.

Совсем три разных вещи.
Структурное -- это без GoTo, как завещал великий Дейкстра.
Процедурное -- это, как ни удивительно, с процедурами.
Декларативное -- это когда описывается результат работы программы, а не процесс его получения (сюда относятся, например, SQL, HTML, XSLT и логическое программирование целиком).

А функциональное - это совсем другое. Лисп, например. Очень, говорят, подходит для обработки (парсинга) текстов.

И для всего остального тоже
Точно так же, как Фортран подходит не только для обработки формул.
И точно так же, как VB -- не "многоцелевой язык для начинающих".
Нельзя название трактовать совсем уж буквально.


Функциональное программирование -- это когда основным объектом программы являются не числа, а функции. Соответственно, функции могут принимать параметрами только функции, возвращать только функции, и внутри себя всяко создавать из одних функций другие.
Числа в этом случае рассматриваются как частный случай функций.

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

[Lumen]

Обеими руками за ООП, ибо рулит.

[tyomitch]

Ааа, так наверное все единогласно голосуют за ООП потому, что другие варианты видят впервые?

[Ramzes]

tyomitch
ну это ты поторопился насчет всех. Я например знаю не только что такое ООП

[tyomitch]

ООП ибо рульно

Ну тогда распиши за рульность ООП.
Холивары ведь создавались именно для аргументированных споров?

[Ramzes]

ООП ибо рульно

Ну тогда распиши за рульность ООП.
Холивары ведь создавались именно для аргументированных споров?

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

[tyomitch]

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

А фраза "чесно говоря даже предстваить себе не могу как это можно сделать без этого" как раз подтверждает мой предыдущий пост

[Ramzes]

tyomitch
то, что немогу представить, это не говорит о том, что не могу сделать.

Что не подтверждает твой пост.

"Аналог" класса можно написать и на QBasic, просто насколько легче работать с кассом!

[tyomitch]

tyomitch
то, что немогу представить, это не говорит о том, что не могу сделать.

Демагогия.
Или ты хочешь сказать, что ты вообще не представляешь, что ты делаешь? По накурке, что ли, программы пишешь?

"Аналог" класса можно написать и на QBasic, просто насколько легче работать с кассом!

Ну и насколько? (Когда же наконец кончатся эмоции, и начнутся аргументы?)

[FaKk2]

tyomitch
Аргументы требуешь
По пунктам:
1. Идеология обьекта со свойствами и методами мне очень импонирует. Гораздо легче оперировать классом чем отдельным сборищем функций в модуле.
2. Наследование и инкапсуляция это тоже очень удобная штука в плане расширяемости и усовершенствования кода.
3. Подумаю еще и добавлю

[tyomitch]

Чем отличаются операции над классом от операций над сборищем функций в модуле?
А именно, в чём различие между вызовами MyObject->MyMethod() и MyMethod(MyObject), где во втором случае MyObject -- обычная структура?
Особенно если учитывать, что компилируются они одинаково

[FaKk2]

tyomitch
А как ты сделаешь коллекцию модулей, будешь наследовать функции чужого модуля и все остальные вкусные штучки?

Кстати, как ты реализуешь MyObject.MyMethod().MyMethod2().... и т.д. в модульном варианте?

[Amed]

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

[tyomitch]

tyomitch
А как ты сделаешь коллекцию модулей, будешь наследовать функции чужого модуля и все остальные вкусные штучки?

Ну, в коллекцию всё равно ложатся структуры с данными, а не функции модуля. Так что это без проблем.

С наследованием чуть хуже, но выкрутиться можно, расширяя в потомке структуру предка вниз. Можно даже виртуальные методы приделать -- точно так же, как их приделывает компилятор.

Кстати, как ты реализуешь MyObject.MyMethod().MyMethod2().... и т.д. в модульном варианте?

Последовательным вызовом: MyMethod(MyObject, &Result); MyMethod2(Result);

И вообще, GDI в WinNT 3.1 компилировалась из C++ в Си, и только потом в машинный код -- так что все объектные выкрутасы достаточно прозрачно переносятся в обычный процедурный код.

[FaKk2]

tyomitch
Ты предлагаешь процедурные аналоги. Но ведь прелесть подхода ООП не в том что он аналогичен процедурному подходу, а тем что он проповедует другую, более информативную, удобную идеологию. В реализации, в конце концов, оба подхода сводятся к одному машинному коду, но идея ведь в другом.

[tyomitch]

Прекрасно. Процедурное программирование сделали, переходим к функциональному.


Вот в перле я могу, на функциональный манер, написать генератор так:

Код: Выделить всё

sub iterator {
  my @array=@_, $index=0;
  sub { $index>$#array? undef: $array[$index++]; }
}


Здесь внутри одной функции мы породили новую функцию-замыкание, с собственным набором локальных переменных.

И потом этот генератор можно вызывать как обычную функцию:

Код: Выделить всё

$i = iterator(1,2,"moo");
while (defined($next=&$i)) { print $next; }


А в ОО-языках я должен был бы вместо этого лепить объект и дёргать его методы. Согласен, что с замыканиями проще?

[tyomitch]

И ещё один примерчик. Пусть мне нужно отсортировать массив, ммм, хитрых структур, по конкретному полю.

Вот в функциональном языке я могу написать (для удобства продолжаю пользоваться синтаксисом перла)

Код: Выделить всё

sub mysort {
  my ($key,@array)=@_;
  qsort (sub { my($a,$b)=@_; ($a->{$key})<=>($b->{$key}); }, @array);
}


А что ты будешь делать со своим ООП
IComparable на классе может быть всего один, значит мимо стандартной релизации сортировки ты пролетаешь. Будешь писать собственную?