Здравствуйте, StevenIvanov, Вы писали:
SI>Здравствуйте, igna, Вы писали:
I>>Является ли STL объектно-ориентированной библиотекой?
SI>Хотелось бы узнать — каков критерий "объектно-ориентированности"? SI>Раз используются объекты — почему нет? SI>Или обязательны жуткие иерархии наследования?
Здравствуйте, igna, Вы писали:
I>Является ли STL объектно-ориентированной библиотекой?
Нет. Сама идея STL в значительной мере ортогональна идеям ООП; автор всегда рассматривал ее как набор универсальных алгоритмов, и сильно плевался по поводу самой парадигмы ООП, которая не позволяет отделить логику от поведения какого-то объекта. STL идеологически гораздо ближе к функциональному программированию.
Реализация STL в С++ естественно использует объекты; но это скорее вынужденная мера, связанная с особенностями языка C++. Так, например, широкое использование функторов является как раз эмуляцией ФП на ООП.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, igna, Вы писали:
I>Является ли STL объектно-ориентированной библиотекой?
STL в основном функционально ориентированная библиотека. Просто в виду того, что С++ мультипарадгмный язык в котором одинаково плохо поддерживаются все парадигмы, фунциональная тоже выглядит убого. В прочем костыли в виде Буста немного исправляют положение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Так, например, широкое использование функторов является как раз эмуляцией ФП на ООП.
Вот это-то в C++ и убивает. Функторы это, конечно хороший механизм, но определять их приходится не "по месту", а черте где — вне функций, а чаще всего в классах. В результате получается каша.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
S>>Так, например, широкое использование функторов является как раз эмуляцией ФП на ООП.
MS>Вот это-то в C++ и убивает. Функторы это, конечно хороший механизм, но определять их приходится не "по месту", а черте где — вне функций, а чаще всего в классах. В результате получается каша.
Здравствуйте, Left2, Вы писали:
MS>>Вот это-то в C++ и убивает. Функторы это, конечно хороший механизм, но определять их приходится не "по месту", а черте где — вне функций, а чаще всего в классах. В результате получается каша.
L>Согласная я!!! Даёшь меанизм замыканий в С++!!!
Ага. Размечталась. Комитет в 2009 собирается включить в язык то, что надо было включать в 1999.
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, Left2, Вы писали:
MS>>>Вот это-то в C++ и убивает. Функторы это, конечно хороший механизм, но определять их приходится не "по месту", а черте где — вне функций, а чаще всего в классах. В результате получается каша.
L>>Согласная я!!! Даёшь меанизм замыканий в С++!!!
M>Ага. Размечталась. Комитет в 2009 собирается включить в язык то, что надо было включать в 1999.
Здравствуйте, Sinclair, Вы писали:
S>Нет. Сама идея STL в значительной мере ортогональна идеям ООП; автор всегда рассматривал ее как набор универсальных алгоритмов, и сильно плевался по поводу самой парадигмы ООП, которая не позволяет отделить логику от поведения какого-то объекта. STL идеологически гораздо ближе к функциональному программированию.
S>Реализация STL в С++ естественно использует объекты; но это скорее вынужденная мера, связанная с особенностями языка C++. Так, например, широкое использование функторов является как раз эмуляцией ФП на ООП.
Объекты — никакая не вынужденная мера. Без использования объектов никакого STL бы в помине не получилось. Итераторы — абстракция контейнера (известная еще с 70-х годов). Устроены разные итераторы по разному, имеют стандартный интерфейс. Итераторы — это самые-пресамые настоящие объекты, никакого отношения к ФП они не имеют. "Алгоритмы" формулируются над итераторами. Единственное что взято из ФП — это функции высокого порядка, которые действительно эмулирутся на функторах и шаблонных функциях. Все.
В результате, STL демонстрирует редкий случай удачного сочетания парадигм ООП и ФП на микроуровне (моя любимая библиотека, кстати, одна из самых простых и красивых штуковин что я видел). Противопоставлять ее и тому и другому — неправильно.
Здравствуйте, Gaperton, Вы писали:
G>Объекты — никакая не вынужденная мера. Без использования объектов никакого STL бы в помине не получилось.
Вот точка зрения основного автора STL на отличие того, чем он занимается, от ООП:
What is the relationship between generic programming and object-oriented programming?
In one sense, generic programming is a natural continuation of the fundamental ideas of object-oriented programming---separating the interface and implementation and polymorphic behavior of the components. However, there is a radical difference. Object-oriented programming emphasizes the syntax of linguistic elements of the program construction. You have to use inheritance, you have to use classes, you have to use objects, objects send messages. Generic programming does not start with the notion of whether you use inheritance or you don't use inheritance. It starts with an attempt to classify or produce a taxonomy of what kinds of things are there and how they behave. That is, what does it mean that two things are equal? What is the right way to define equality? Not just actions of equality. You can analyze equality deeper and discover that there is a generic notion of equality wherein two objects are equal if their parts, or at least their essential parts are equal. We can have a generic recipe for an equality operation. We can discuss what kinds of objects there are. There are sequences. There are operations on sequences. What are the semantics of these operations? What types of sequences from the point of view of complexity tradeoffs should we offer the user? What kinds of algorithms are there on sequences? What kind of different sorting functions do we need? And only after we develop that, after we have the conceptual taxonomy of the components, do we address the issue of how to implement them. Do we use templates? Do we use inheritance? Do we use macros? What kind of language technology do we use? The fundamental idea of generic programming is to classify abstract software components and their behavior and come up with a standard taxonomy. The starting point is with real, efficient algorithms and data structures and not with the language. Of course, it is always embodied in the language. You cannot have generic programming outside of a language. STL is done in C++. You could implement it in Ada. You could implement it in other languages. They would be slightly different, but there are some fundamental things that would be there. Binary search has to be everywhere. Sort has to be everywhere. That's what people do. There will be some modification on the semantics of the containers, slight modifications imposed by the language. In some languages you can use inheritance more, in some languages you have to use templates. But the fundamental difference is precisely that generic programming starts with semantics and semantic decomposition. For example, we decide that we need a component called swap. Then we figure out how this particular component will work in different languages. The emphasis is on the semantics and semantic classification, while object-orientedness, especially as it has evolved, places a much stronger emphasis, and, I think, too much of an emphasis, on precisely how to develop things, that is, using class hierarchies. OOP tells you how to build class hierarchies, but it doesn't tell you what should be inside those class hierarchies.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>Объекты — никакая не вынужденная мера. Без использования объектов никакого STL бы в помине не получилось. S>Вот точка зрения основного автора STL на отличие того, чем он занимается, от ООП:
Мне знакома его точка зрения. При этом, общеизвестно также, что он не является экспертом в ООП. У него получилась классная библиотека, за что ему спасибо. Это не означает, что если он скажет тебе какую-нибудь глупость — например, выпрыгнть в окно, то надо не раздумывая так и делать. Естественно, ему хочется претендовать на то, что он изобрел радикально новый, принципиально отличный от всего существующего подход. Но он в этом не прав — в мире вообще очень мало по настоящему оригинальных вещей.
Вот смотри: S>
However, there is a radical difference. Object-oriented programming emphasizes the syntax of linguistic elements of the program construction. You have to use inheritance, you have to use classes, you have to use objects, objects send messages. Generic programming does not start with the notion of whether you use inheritance or you don't use inheritance. It starts with an attempt to classify or produce a taxonomy of what kinds of things are there and how they behave.
Ну во-первых, наследование без необходимости никто использовать не обязан (кстати, в реализациях STL активно испльзуется наследование. Рекомендую заглянуть). Более того, в определении объектной системы Алана Кея нет никакого упоминания о наследовании.
Во-вторых, я не понимаю трагизма того, что мне надо использовать классы и объекты. Если Степанову не нравится названия "класс", "объект", "сообщение" — пусть назовет хоть "жопой". В любом случае ему понадобится способ выставить абстрактный интерфейс и спрятать состояние, т.е. другими словами ему понадобится "объект", хочет он этого, или нет. Объект не перестанет быть объектом, как его не называй. А вот без классов можно обойтись, и ничего страшного не случится. Например, в динамическом языке. И система все равно будет объектной по определению Кея.
В третьих, когда он переходит к описанию подхода generic programming он почему-то ловко переходит на процесс проектирования (кстати, так же и объектная система проектируется — ну просто слово в слово). Непонятно, кого он хочет обмануть. ООП (и проектирование ОО системы) тоже начинается совсем не с того, надо нам или не надо применять наследование, и куда все-таки вкрячить эти дурацкие классы (это у студентов он только так начинается, да и то только у самых тупых).
Так что это мнение, Синклер, во-первых — мнение Степанова, если я не ошибаюсь, а не твое, во вторых, ну никак не подтверждает твой тезис.
Здравствуйте, Gaperton, Вы писали:
G>Мне знакома его точка зрения. При этом, общеизвестно также, что он не является экспертом в ООП.
Не бывает экспертов в ООП или там в метапрограммировании. Бывают эксперты просто в программировании. А если человек начинает разбираться где ООП, а где нет — он скорее философ.
Здравствуйте, machine3000, Вы писали:
G>>Мне знакома его точка зрения. При этом, общеизвестно также, что он не является экспертом в ООП.
M>Не бывает экспертов в ООП или там в метапрограммировании. Бывают эксперты просто в программировании. А если человек начинает разбираться где ООП, а где нет — он скорее философ.
Хорошему инженеру-программисту вообще-то неплохо уметь разбираться, где ООП, а где нет. Но не обязательно. Умение делать классные штуки гораздо важнее.
Но это не означает, что если Степанов скажет выпрыгнуть в окно, то надо перевести мозги на позицию "офф" и так и сделать. У хорошего инженера должно быть свое собственное мнение. И он должен уметь его защищать. Это не прерогатива философов.
Здравствуйте, Gaperton, Вы писали:
G>Хорошему инженеру-программисту вообще-то неплохо уметь разбираться, где ООП, а где нет. Но не обязательно. Умение делать классные штуки гораздо важнее.
От того является код ОО или нет в общем случае он лучше не становится. Важно видеть какие приёмы программирования оптимально подходят для решения конкретной задачи и совершенно никакого значения не имеет к каким парадигмам они при этом относятся.
G>Но это не означает, что если Степанов скажет выпрыгнуть в окно, то надо перевести мозги на позицию "офф" и так и сделать. У хорошего инженера должно быть свое собственное мнение. И он должен уметь его защищать. Это не прерогатива философов.
По поводу выпригивания в окно — должно, по поводу парадигм — вопрос спорный. Чем меньше инженер будет спорить, где ООП, а где нет — тем больше времени у него останется на написание кода.
Здравствуйте, Gaperton, Вы писали:
G>В результате, STL демонстрирует редкий случай удачного сочетания парадигм ООП и ФП на микроуровне (моя любимая библиотека, кстати, одна из самых простых и красивых штуковин что я видел). Противопоставлять ее и тому и другому — неправильно.
Хм, и это несмотря на то, что ты знаешь, что сам Степанов не считает свою STL объектно-ориентированной. Может быть дело в определении, вот например что написал Саттер:
Well, what is object orientation, anyway? Even at this late date, if you ask 10 people, you're likely to get 15 different answers.
Для меня ООП на C++ приблизительно равно использованию слова virtual, хотя конечно и на С можно сэмулировать объектную ориентированность, и напротив на C++ можно писать virtual везде, где позволяет компилятор не пользуясь возможностями, которые этот самый virtual дает, но в целом для меня virtual == OOP, а для тебя скорее всего нет.
Здравствуйте, Gaperton, Вы писали:
G>В любом случае ему понадобится способ выставить абстрактный интерфейс и спрятать состояние, т.е. другими словами ему понадобится "объект", хочет он этого, или нет.
А разве нельзя обойтись абстрактным типом данных?
Если Степанову не нравится названия "класс", "объект", "сообщение" — пусть назовет хоть "жопой". В любом случае ему понадобится способ выставить абстрактный интерфейс и спрятать состояние, т.е. другими словами ему понадобится "объект", хочет он этого, или нет. Объект не перестанет быть объектом, как его не называй. А вот без классов можно обойтись, и ничего страшного не случится. Например, в динамическом языке. И система все равно будет объектной по определению Кея.
