Vex, просто для справки - ты когда писал (или пишешь) на дельфи - ты придерживался процедурного или объектно ориентированного программирования? 



OMG!

Согласен, точнее будет "сокрытие <- инкапсуляция"   


Давай напиши одну единственную функцию, которая умеет открывать/закрывать системный COM-порт, принимать и посылать через него байтики, всячески им руководить и буферизовать данные, при этом не вываливая наружу сам порт, всё его состояние и вспомогательный функционал. Ну даже совокупность функций, жонглирующих переменными. И внезапно окажется, что всё это может быть удобно (sic!) инкапсулировано в объекте.


Интересная, кстати, работа, я бы на это посмотрел и даже поучаствовал (хинт: смотри поле "где" в окошке информации о пользователе форума). Однако грамотное спаривание подразумевает работу интерфейсами, и при правильно спроектированной архитектуре можно подменить один сервис другим, ни капли не меняя в остальной программе. Это и есть инкапсуляция. Примеры можно нагуглить по словам Dependency Injection Framework и Inversion of Control.


Ну можно же было использовать друзей!   
Ответь, пожалуйста, на один вопрос - а почему тогда не public? Зачем эти странности с правами доступа, если самому же их приходится хитрым противоестественным образом обходить?


В чём проблема "комплексности ООП", почему кусочками оно хорошо, а целиком плохо, можно пример?
В чём проблема статичности "не труъ-ООП"? Статика и динамика - это вообще-то вопрос реализации типизации в языке, не более того. Какое несомненное преимущество имеет динамический язык по сранению со статическим, на твой взгляд?
В питоне типизация динамическая, он труъ-ООП язык? В лиспе типизация динамическая, он труъ-ООП язык? 




Имеется в виду именно функциональный стиль, примеры реализации контейнеров в OCaml, Haskell, Lisp, Erlang иже с ними. Но там другая среда исполнения, сборщик мусора сам следит за временем жизни хранимых объектов.

Я конечно дико извиняюсь за то, что лезу в столь высокоинтеллектуальные вопросы, не внеся свою лепту в дискуссию (неохота холиварить, мне здесь больше нравиться роль независимого зрителя с попкорном  )  но если речь все еще про C# то я не знаю где Вы его учили

и тоже самое на C++ - раз (по старому стандарту)

и два (по новому, смотрите скоро, на первом канале)

разве нужно что-то еще?

Это сообщение отредактировал(а) azesmcar - 29.9.2010, 09:35

а если дизассемблировать и посмотреть что на самом деле происходит   

хотя прикрутить делегат и заюзать лямбду или анонимный метод - отличный ответ на претензии.  

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

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

Это сообщение отредактировал(а) azesmcar - 29.9.2010, 10:26

да нет..это я шучу так  
на самом деле я предложил это как альтернативу, которая решает твою задачу.


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


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

Это сообщение отредактировал(а) smartov - 4.10.2010, 14:06

в таком случае:



обычно я этим и занимаюсь   

и это правильно, главное, что за это платят  

А если дизассемблировать код с дельфи - о, ужас, вообще функций нету  


Во-первых, дело не в .Net а в шарпе. Во-вторых, анонимные делегаты были во 2-ом ещё (шарпе). Лямбды и анонимные делегаты и есть "локальные функции".


Ну что-т тип такого (если что - яверы поправят красивее):


И самое интересное. И шарповские делегаты (неважно откуда они взялись - явный метод, анонимный делегат или лямбда) и даже яверная чисто ООП-шная реализация круче чем то, что в Дельфи, хотя бы потому, что это первоклассные сущности. А в дельфи для вложенных функций это неприменимо (по крайней мере в те времена, когда я это видел). Как написать на дельфи что-то вроде банального collection.Where(x => x > 5)?

А вообще - это полный оффтопик  

ООП не метод, а методология. Как любая методология для применения требует еще толику мозгов. И понимания, какую именно методологию полезно применять в конкретном случае. ОО это подход, и MAKCim абсолютно прав.
Что касается языков - дело вкуса. С++ поддерживает 3.5 парадигмы (0.5 на функциональное), что позволяет для большинства задач выбрать средство, оставаясь в пространстве языка. Выгода в краткости и читабельности кода.

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

ЗЫ: Мнение А.Степанова насчет объектов/алгоритмов и сравнение с аксиомами/доказательствами имхо весьма слабая позиция. Если интересно, могу развить.

 он разве серьезный ?   


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

Добавлено через 3 минуты и 4 секунды

но где то в глубине все ж проглядывает здравая и интересная мысль.  наверно просто программирование еще не доросло до этого..


с удовольствием бы выслушал бы Ваше мнение по этому поводу.

Буду краток)))

Начну с тривиального постулата, что универсальных инструментов не бывает.
Помимо ОО подхода есть и множество других. На разных этапах и для разных частей задачи одни будут иметь преимущество перед другими, поэтому вопрос OOP vs Generic vs Functional vs ... вообще не стоит.

Степанов в интервью говорит:

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

2. философски несостоятельным, потому что "все есть объект". "Даже если это правда, это не очень интересно: сказать, что все является объектом значит не сказать ничего."
Я лично ничего против объектной философии не имею, т.к. все действительно можно представить в виде объектов. Кто-нить приведет пример, когда это не так? Степанов тоже не может, иначе он сказал бы об альтернативе и не сказал бы "даже если это правда".
Представление в виде объектов, конечно, не панацея, но в целом вполне удобный прием абстрагирования.
Кстати, сравните с философией Unix "все есть файл". 

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

Вот где-то так. Извините, что длинно, но и здесь не все поместилось))

Я кстати не верю, что Степанов действительно так считает. Скорее истина подавлена хорошим слогом ради красивого интервью.

Решил еще 5 копеек добавить для ясности.

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

наченем с философии.. 

можно, но относительно.. 
Выражение "все есть объект"  должно накладывать некие отличительные признаки и обладать некоторыми гарантиями,
иначе ничем не будет отличаться от "не все есть объект" 
Страуструп в этом вопросе подерживает Степанова, и считает что "все есть void*", ибо делать все объектами несет дополнительные расходы и не согласуется с идеологией C++   

P.S.  некоторые моменты обострил специально для краткости..