Сообщение Re[7]: Базовое отличие ООП от ФП от 21.05.2024 13:20
Изменено 21.05.2024 13:40 Serginio1
Re[7]: Базовое отличие ООП от ФП
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Ну ООП это не только состояние. Но самое главное это наследование полей, свойств методов и их переопределение.
S>Наследование полей как раз самое неглавное. Например, в COM нет никакого наследования полей, что не мешает ему быть ОО-платформой.
В Delphi интересно сделали поддержку интерфейсов. Делали отдельную VMT для каждого объекта где перед вызовом метода корректировался Self.
В COM нет полей, но есть VMT.
S>>VMT! Интерфейсы! Видимость свойств и методов.
S>VMT — это деталь реализации. Можно строить ООП существенно по-другому.
S>В том же Object Pascal (aka Delphi) есть две разных VMT.
На самом деле одна. Просто с отрицательным смещением идет VMT для метаклассов. (class procedure DoSomething;override![](/Forum/Images/wink.gif)
S>> Ref тоже могут быть read only readonly ref
S>>Да иногда сложно читать код. Тыкаешь в метод и попадаешь либо в абстрактный либо виртуальный метод. Нужно смотреть реализацию, которая может быть у десятков и сотен классов.
S>Не в этом дело.
S>> Вот в C# для структур нет наследования, хотя могли бы и завести тип структура с VMT как в C++
S>Нет смысла. Наследование структур в .Net имело бы весьма ограниченную полезность.
S>Наследование имеет смысл там, где можно выполнять принцип подстановки, а для этого нужна ссылка, а не экземпляр.
S>То есть, к примеру, не получится объявить var b = BaseStruct[] и положить в него b[0] = new DerivedStruct().
S>Чтобы это было можно,
S>а) элементы массива должны быть ссылками
S>б) в каждой ссылке должна быть информация о типе, чтобы GC мог правильно интерпретировать то, на что она указывает.
S>Получаем, собсно, reference type aka class.
S>Весь полиморфизм value-типов, который возможен в рамках управляемой среды, будет жить исключительно на стеке.
S>То есть там, где можно получить некий ref. И тогда понятно, что можно в качестве ref baseStruct передать ref DerivedStruct.
Ну вот С++ прекрасно себе используют структуры и не кашляют.
Можно создать ограничения итд. А так приходится наследоваться через Агрегирование.
Кстати в том же Delphi есть Implements то есть полю делегируют реализацию интерфейса
S>Здравствуйте, Serginio1, Вы писали:
S>> Ну ООП это не только состояние. Но самое главное это наследование полей, свойств методов и их переопределение.
S>Наследование полей как раз самое неглавное. Например, в COM нет никакого наследования полей, что не мешает ему быть ОО-платформой.
В Delphi интересно сделали поддержку интерфейсов. Делали отдельную VMT для каждого объекта где перед вызовом метода корректировался Self.
В COM нет полей, но есть VMT.
S>>VMT! Интерфейсы! Видимость свойств и методов.
S>VMT — это деталь реализации. Можно строить ООП существенно по-другому.
S>В том же Object Pascal (aka Delphi) есть две разных VMT.
На самом деле одна. Просто с отрицательным смещением идет VMT для метаклассов. (class procedure DoSomething;override
![](/Forum/Images/wink.gif)
S>> Ref тоже могут быть read only readonly ref
S>>Да иногда сложно читать код. Тыкаешь в метод и попадаешь либо в абстрактный либо виртуальный метод. Нужно смотреть реализацию, которая может быть у десятков и сотен классов.
S>Не в этом дело.
S>> Вот в C# для структур нет наследования, хотя могли бы и завести тип структура с VMT как в C++
S>Нет смысла. Наследование структур в .Net имело бы весьма ограниченную полезность.
S>Наследование имеет смысл там, где можно выполнять принцип подстановки, а для этого нужна ссылка, а не экземпляр.
S>То есть, к примеру, не получится объявить var b = BaseStruct[] и положить в него b[0] = new DerivedStruct().
S>Чтобы это было можно,
S>а) элементы массива должны быть ссылками
S>б) в каждой ссылке должна быть информация о типе, чтобы GC мог правильно интерпретировать то, на что она указывает.
S>Получаем, собсно, reference type aka class.
S>Весь полиморфизм value-типов, который возможен в рамках управляемой среды, будет жить исключительно на стеке.
S>То есть там, где можно получить некий ref. И тогда понятно, что можно в качестве ref baseStruct передать ref DerivedStruct.
Ну вот С++ прекрасно себе используют структуры и не кашляют.
Можно создать ограничения итд. А так приходится наследоваться через Агрегирование.
Кстати в том же Delphi есть Implements то есть полю делегируют реализацию интерфейса
Re[7]: Базовое отличие ООП от ФП
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Ну ООП это не только состояние. Но самое главное это наследование полей, свойств методов и их переопределение.
S>Наследование полей как раз самое неглавное. Например, в COM нет никакого наследования полей, что не мешает ему быть ОО-платформой.
В Delphi интересно сделали поддержку интерфейсов. Делали отдельную VMT для каждого объекта где перед вызовом метода корректировался Self.
В COM нет полей, но есть VMT.
S>>VMT! Интерфейсы! Видимость свойств и методов.
S>VMT — это деталь реализации. Можно строить ООП существенно по-другому.
S>В том же Object Pascal (aka Delphi) есть две разных VMT.
На самом деле одна. Просто с отрицательным смещением идет VMT для метаклассов. (class procedure DoSomething;override![](/Forum/Images/wink.gif)
Нужны ли метаклассы????1
S>> Ref тоже могут быть read only readonly ref
S>>Да иногда сложно читать код. Тыкаешь в метод и попадаешь либо в абстрактный либо виртуальный метод. Нужно смотреть реализацию, которая может быть у десятков и сотен классов.
S>Не в этом дело.
S>> Вот в C# для структур нет наследования, хотя могли бы и завести тип структура с VMT как в C++
S>Нет смысла. Наследование структур в .Net имело бы весьма ограниченную полезность.
S>Наследование имеет смысл там, где можно выполнять принцип подстановки, а для этого нужна ссылка, а не экземпляр.
S>То есть, к примеру, не получится объявить var b = BaseStruct[] и положить в него b[0] = new DerivedStruct().
S>Чтобы это было можно,
S>а) элементы массива должны быть ссылками
S>б) в каждой ссылке должна быть информация о типе, чтобы GC мог правильно интерпретировать то, на что она указывает.
S>Получаем, собсно, reference type aka class.
S>Весь полиморфизм value-типов, который возможен в рамках управляемой среды, будет жить исключительно на стеке.
S>То есть там, где можно получить некий ref. И тогда понятно, что можно в качестве ref baseStruct передать ref DerivedStruct.
Ну вот С++ прекрасно себе используют структуры и не кашляют.
Можно создать ограничения итд. А так приходится наследоваться через Агрегирование.
Кстати в том же Delphi есть Implements то есть полю делегируют реализацию интерфейса
S>Здравствуйте, Serginio1, Вы писали:
S>> Ну ООП это не только состояние. Но самое главное это наследование полей, свойств методов и их переопределение.
S>Наследование полей как раз самое неглавное. Например, в COM нет никакого наследования полей, что не мешает ему быть ОО-платформой.
В Delphi интересно сделали поддержку интерфейсов. Делали отдельную VMT для каждого объекта где перед вызовом метода корректировался Self.
В COM нет полей, но есть VMT.
S>>VMT! Интерфейсы! Видимость свойств и методов.
S>VMT — это деталь реализации. Можно строить ООП существенно по-другому.
S>В том же Object Pascal (aka Delphi) есть две разных VMT.
На самом деле одна. Просто с отрицательным смещением идет VMT для метаклассов. (class procedure DoSomething;override
![](/Forum/Images/wink.gif)
Нужны ли метаклассы????1
S>> Ref тоже могут быть read only readonly ref
S>>Да иногда сложно читать код. Тыкаешь в метод и попадаешь либо в абстрактный либо виртуальный метод. Нужно смотреть реализацию, которая может быть у десятков и сотен классов.
S>Не в этом дело.
S>> Вот в C# для структур нет наследования, хотя могли бы и завести тип структура с VMT как в C++
S>Нет смысла. Наследование структур в .Net имело бы весьма ограниченную полезность.
S>Наследование имеет смысл там, где можно выполнять принцип подстановки, а для этого нужна ссылка, а не экземпляр.
S>То есть, к примеру, не получится объявить var b = BaseStruct[] и положить в него b[0] = new DerivedStruct().
S>Чтобы это было можно,
S>а) элементы массива должны быть ссылками
S>б) в каждой ссылке должна быть информация о типе, чтобы GC мог правильно интерпретировать то, на что она указывает.
S>Получаем, собсно, reference type aka class.
S>Весь полиморфизм value-типов, который возможен в рамках управляемой среды, будет жить исключительно на стеке.
S>То есть там, где можно получить некий ref. И тогда понятно, что можно в качестве ref baseStruct передать ref DerivedStruct.
Ну вот С++ прекрасно себе используют структуры и не кашляют.
Можно создать ограничения итд. А так приходится наследоваться через Агрегирование.
Кстати в том же Delphi есть Implements то есть полю делегируют реализацию интерфейса