Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 2956 22-02-2007 15:13 | |
№ 2955 22-02-2007 14:49 | |
Ответ на »сообщение 2954« (Jack Of Shadows)
___________________________
Ну, тогда жаль. "Вульгарное ООП всюду дотянулось" :-)
№ 2954 22-02-2007 14:42 | |
Ответ на »сообщение 2953« (Илья Ермаков)
___________________________
Неверно. В класс типа можно включать реализации функций (в отличии от интерфейсов) и эти реализации будут использоваться производными типами (то что в ООП называется наследниками) в случае если эти производные типы не предоставили свои реализации функций.
№ 2953 22-02-2007 14:32 | |
Ответ на »сообщение 2952« (Geniepro)
___________________________
Класс в Хаскеде - это фактически описание чистого интерфейса. Когда мы декларируем принадлежность типа классу, мы явно коммутируем операции типа к операциям интерфейса.
№ 2952 22-02-2007 14:19 | |
Ответ на »сообщение 2950« (Илья Ермаков)
___________________________
Однако при этом мы явно коммутируем методы для повторного использования. Это подобно ООП в классическом Обероне.
Какая явная коммутация методов в Хаскелле? Вы можете пояснить эту мысль кодом?
№ 2951 22-02-2007 14:03 | |
Ответ на »сообщение 2947« (Илья Ермаков)
___________________________
Наверное, следует добавить к ранее сказанному, что Хаскелл, вапще-то, не объектно-ориентированный язык... Так что эта фраза:
И ООП, вообще говоря, не подразумевает обязательной возможности повторного использование через наследование. Вон в Хацкеле такого нет.
непонятно к чему сказана...
№ 2950 22-02-2007 13:34 | |
Ответ на »сообщение 2949« (Jack Of Shadows)
___________________________
Однако при этом мы явно коммутируем методы для повторного использования. Это подобно ООП в классическом Обероне. При этом система не теряет гибкости, в отличие от "топорного" мейнстримовского ООП.
№ 2949 22-02-2007 12:36 | |
Ответ на »сообщение 2947« (Илья Ермаков)
___________________________
Вон в Хацкеле такого нет.
Почему нет ? Создаете новый тип, наследуя его от Eq, Ord, предоставляете необходимую реализацию операции сравнения (для Eq).
Операции >, < >= <= наследуются из Ord автоматически.
Вот вам и повторное использование кода - через наследование.
№ 2948 22-02-2007 12:32 | |
Ответ на »сообщение 2947« (Илья Ермаков)
___________________________
И ООП, вообще говоря, не подразумевает обязательной возможности повторного использование через наследование. Вон в Хацкеле такого нет.
Там больше есть. Там можно в классе определить функцию, которая будет использоваться в типе (реализации этого класса), если в последнем она не определена. Но, конечно же, этот меканизьм "не совсем наследование". В том смысле, как его понимает всё остальное "ООПрегрессивное" человечество.
№ 2947 22-02-2007 12:20 | |
Ответ на »сообщение 2944« (Сергей Перовский)
___________________________
Ответ на »сообщение 2938« (Как слышно? Приём!)
___________________________
Отношение наследования это отношение между большей и меньшей абстракцией.
Парадигма наследования состоит всего лишь в том, что одинаковые части должны быть сделаны однократно.
Вот кстати... В ваших двух выссказываниях очень четко выразилась суть проблемы.
Наследование имеет два контекста - во-первых, выстраивание отношений "род-вид" и родовой полиморфизм, а во-вторых - повторное использование кода.
Первое - это хорошо. Всегда хороша возможность статически выразить какие-то отношения в программе. Однако все прекрасно именно тогда, когда эти отношения мы выстраиваем между интерфейсами, и хорошо продуманными интерфейсами.
А вот повторное использование через ООП часто делается очень неудачно и нарушает гибкость программной системы.
И ООП, вообще говоря, не подразумевает обязательной возможности повторного использование через наследование. Вон в Хацкеле такого нет.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|