Аннотация:
Сейчас преимущества использования объектов очевидны для всех. Однако так было не всегда. Сначала старая гвардия не поняла и не приняла объекты, поэтому они почти 20 лет потихоньку развивались в различных языках, первым из которых была Simula 67. Постепенно объектно-ориентированный подход нашел себе место и в более мощных языках, таких как C++, Delphi и множестве других языков. Блестящим примером реализации объектов была библиотека Turbo Vision, предназначенная для построения пользовательского интерфейса программ в операционной системе MS-DOS.
Полную победу объекты одержали с приходом эпохи многофункциональных графических пользовательских интерфейсов. Теперь без объектов в программировании просто не обойтись. Чтобы вы не рылись в других книгах, собирая информацию по крохам, мы не поленились и объединили в этой главе все, что нужно знать об объектах. Для новичка важнейшее здесь: инкапсуляция, наследование, полиморфизм, остальное можно просто просмотреть и возвращаться к материалу по мере накопления опыта. Профессионалу полезно прочитать внимательно все от начала до конца. Поэтому давайте засучим рукава и приступим к делу.
> Третий кит — это полиморфизм. Он означает, что в производных классах вы можете изменять работу уже существующих в базовом классе методов. При этом весь программный код, управляющий объектами родительского класса, пригоден для управления объектами дочернего класса без всякой модификации.
Какое-то неправильное у вас определение полиморфизма — слишком конкретное.
Полиморфизм, вообще говоря, позволяет вызывать методы и свойства объекта, ничего не зная об их реализации. Это позволяет реализовать один и тот же интерфейс (набор свойств и методов) в различных классах. Получается, что наследование — это один из способов реализации полиморфизма. А у вас получается всё наоборот — полиморфизм определяется используя понятие наследования.
Второй способ реализации полиморфизма — через интерфейсы. Об этом в статье вообще ничего не увидел.
Здравствуйте, nzeemin, Вы писали:
>> Третий кит — это полиморфизм. Он означает, что в производных классах вы можете изменять работу уже существующих в базовом классе методов. При этом весь программный код, управляющий объектами родительского класса, пригоден для управления объектами дочернего класса без всякой модификации.
N>Полиморфизм, вообще говоря, позволяет вызывать методы и свойства объекта, ничего не зная об их реализации.
Хм...
Инкапсуляция — это возможность скрыть внутренние детали при описании общего интерфейса.
Поэтому она вроде "позволяет вызывать методы и свойства объекта, ничего не зная об их реализации"
Полиморфизм — это возможность посылать одно и то же сообщение разным (!!!) типам данных.
И, грубо говоря, он не позволяет (!!!) оторваться от реализации каждого конкретного типа данных.
Здравствуйте, kavlad, Вы писали:
N>>Полиморфизм, вообще говоря, позволяет вызывать методы и свойства объекта, ничего не зная об их реализации. K>Инкапсуляция — это возможность скрыть внутренние детали при описании общего интерфейса. K>Поэтому она вроде "позволяет вызывать методы и свойства объекта, ничего не зная об их реализации" K>Полиморфизм — это возможность посылать одно и то же сообщение разным (!!!) типам данных. K>И, грубо говоря, он не позволяет (!!!) оторваться от реализации каждого конкретного типа данных.
Возможно несколько неточно выразился. Попробую еще раз.
Инкапсуляция позволяет отделить реализацию объекта от его внешнего описания (интерфейса) — путём сокрытия членов класса и предоставления доступа только через свойства/методы.
Полиморфизм позволяет реализовать один и тот же интерфейс в разных классах, что дает возможность вызывать методы/свойства разных классов, пользуясь лишь общим внешним описанием метода/класса/интерфейса. В результате мы можем написать функцию/процедуру, выполняющуюся над произвольным классом, наследованным от данного, либо над произвольным классом, поддерживающим данный интерфейс.
Здравствуйте, nzeemin, Вы писали:
>> Третий кит — это полиморфизм. Он означает, что в производных классах вы можете изменять работу уже существующих в базовом классе методов. При этом весь программный код, управляющий объектами родительского класса, пригоден для управления объектами дочернего класса без всякой модификации.
N>Какое-то неправильное у вас определение полиморфизма — слишком конкретное.
N>Полиморфизм, вообще говоря, позволяет вызывать методы и свойства объекта, ничего не зная об их реализации. Это позволяет реализовать один и тот же интерфейс (набор свойств и методов) в различных классах. Получается, что наследование — это один из способов реализации полиморфизма. А у вас получается всё наоборот — полиморфизм определяется используя понятие наследования.
С этим уже разобрались.
N>Второй способ реализации полиморфизма — через интерфейсы. Об этом в статье вообще ничего не увидел.
Там определение полиморфизма дано так: "In computer science, polymorphism is the idea of allowing the same definitions to be used with different types of data (specifically, different classes of objects), resulting in more general and abstract implementations".
Во-первых, полиморфизм — это не идея, а термин, обозначающий явление. Во-вторых, при объяснении термина нужно исходить из гносиологии слова. Слово полиморфизм произошло из словосочетания "многообразие форм". Этим словосочетанием обозначают явление, при котором объект как бы меняет форму (тип) при работе его методов. Например, если объект O2 класса C2 унаследовал от некоторого базового класса C1 метод M1, то при вызове этого метода из объекта O2 объект "прикидывается" будто принадлежит классу C1. Если далее из метода M1 вызывается некоторый виртуальный метод M2, перекрытый в классе С2, объект проявляет свой реальный тип. Иначе говоря, от процедуры к процедуре объект как бы меняет форму (тип). Получается, что полиморфизм — это прижившаяся метафора. На самом деле, термины "полиморфизм", "наследование" и многие другие являются жаргонными. Они не приближают нас к пониманию сути объектного программирования. Их приходится вводить лишь постольку, поскольку ими пользуются в других книгах.
Здравствуйте, Аноним, Вы писали:
А>Слово полиморфизм произошло из словосочетания "многообразие форм". Этим словосочетанием обозначают явление, при котором объект как бы меняет форму (тип) при работе его методов.
А я считаю, что прав nzeemin, т.к. таким же словосочетанием "многообразие форм" можно обозначить и тот факт, что объект с точки зрения различных контактеров может иметь различные интерфейсы ("формы"). И, по-моему, именно это и будет наиболее широкой трактовкой понятия полиморфизма.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Аноним, Вы писали:
N>>А у вас получается всё наоборот — полиморфизм определяется используя понятие наследования. А>С этим уже разобрались.
Не факт. Так и остались две точки зрения.
N>>Второй способ реализации полиморфизма — через интерфейсы. Об этом в статье вообще ничего не увидел. А>Интерфейсы рассмотрены в главе 6.
Так надо бы упомянуть, что есть и такое проявление полиморфизма. И отослать к главе 6.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Re[6]: Полиморфизм
От:
Аноним
Дата:
27.11.05 17:49
Оценка:
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Здравствуйте, Аноним, Вы писали:
А>>Слово полиморфизм произошло из словосочетания "многообразие форм". Этим словосочетанием обозначают явление, при котором объект как бы меняет форму (тип) при работе его методов. SM>А я считаю, что прав nzeemin, т.к. таким же словосочетанием "многообразие форм" можно обозначить и тот факт, что объект с точки зрения различных контактеров может иметь различные интерфейсы ("формы"). И, по-моему, именно это и будет наиболее широкой трактовкой понятия полиморфизма.
Термин "полиморфизм" был введен еще тогда, когда интерфейсов в языке Delphi не было. Тем не менее, Вы правы, многообразие форм очень удобно объяснять на примере интерфейсов.
Здравствуйте, Аноним, Вы писали:
SM>>А я считаю, что прав nzeemin, т.к. таким же словосочетанием "многообразие форм" можно обозначить и тот факт, что объект с точки зрения различных контактеров может иметь различные интерфейсы ("формы"). А>Термин "полиморфизм" был введен еще тогда, когда интерфейсов в языке Delphi не было. Тем не менее, Вы правы, многообразие форм очень удобно объяснять на примере интерфейсов.
Ну что вы, я имел в виду более широкое толкование интерфейса Как протокола обращения "внешнего мира" к функциональности объекта.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Еще я бы предложил сразу заложить основу для понимания Class References и виртуального конструирования.
То есть упомянуть (перед частью 3.3) вот о чем:
Класс может содержать методы для обработки описанных в нем данных, но может содержать и методы, не зависящие от данных. Первые в ООП называют instance methods, вторые — class methods. Синтаксис вызова class methods в Delphi такой: <class_name>.<method_name>.
Но как же перейти от класса к экземпляру, чтобы можно было использовать instance methods? В Delphi именно класс содержит метод, который позволяет создавать экземпляры этого класса. Это, стало быть, constructor. Он (для начала упростим) выделяет память, инициализирует данные и возвращает указатель на экземпляр. В дальнейшем при вызове instance-методов через этот указатель они будут работать именно с данными этого экземпляра. Синтаксис выглядит так: (ну и тут пример с Create и NextLine). Через этот указатель можно вызывать и class methods.
Есть и другие class-методы, к тому же можно создавать свои, но об этом будет сказано позднее в разделе xxx.xxx
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, А.Н. Вальвачев, К.А. Сурков, Д.А. Сурков, Ю.М. Чет, Вы писали:
>>Процедуры и функции, предназначенные для выполнения над объектами действий, называются методами. Предварительное объявление методов выполняется при описании класса в секции interface модуля, а их программный код записывается в секции implementation.
А объявить класс в Implementation низзя?
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Последние замечания на сегодня. Надо бы сказать, что все, о чем там говорится, относится к т.н. объектам нового стиля (которые объявляются через class). Существуют также объекты старого стиля (object), на которые распространяется многое из вышесказанного, но все-таки не все.
Ну и где-нибудь дальше в книжке описать, что это за фича и зачем она нужна.
Про метаклассы надо бы написать, что на них тоже определено отношение наследования. Вернее, если плясать не от термина "метакласс", а так, как я предлагал в одном из предыд. постингов, то это будет само собой разумеющимся — но про возможность применения as/is к Class reference все равно стоит упомянуть.
А! Еще про TMethod забыли. Ну, можно упомянуть, а потом описать более подробно (когда расскажете, как именно располагается в памяти объекты). Кстати, вы, по-моему, этот момент пропустили в изложении: >Переменная такого типа называется указателем на метод (method pointer). Она занимает в памяти 8 байт и хранит одновременно ссылку на объект и адрес его метода
Но разве к этому моменту сказано, зачем нужен адрес объекта, если уже есть адрес метода? Т.е. надо или промолчать насчет этого и описать потом, или пояснить, что, т.к. методы для всех экземпляров класса одинаковы, то экземпляр содержит только данные (ну и VMT), а программный код методов хранится в единственном варианте, отдельно от экземпляров. Т.о., для вызова метода недостаточно знать его адрес, а надо знать еще, к какому экземпляру следует его применить. Поэтому-то при взятии адреса метода некоторого объекта берется не только адрес самого кода метода, но и адрес объекта.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, nzeemin, Вы писали:
>> Третий кит — это полиморфизм. Он означает, что в производных классах вы можете изменять работу уже существующих в базовом классе методов. При этом весь программный код, управляющий объектами родительского класса, пригоден для управления объектами дочернего класса без всякой модификации.
N>Какое-то неправильное у вас определение полиморфизма — слишком конкретное.
N>Полиморфизм, вообще говоря, позволяет вызывать методы и свойства объекта, ничего не зная об их реализации. Это позволяет реализовать один и тот же интерфейс (набор свойств и методов) в различных классах. Получается, что наследование — это один из способов реализации полиморфизма. А у вас получается всё наоборот — полиморфизм определяется используя понятие наследования.
N>Второй способ реализации полиморфизма — через интерфейсы. Об этом в статье вообще ничего не увидел.
А есть еще третий — через перегрузку методов. ИМХО.
It is always bad to give advices, but you will be never forgiven for a good one.
Oscar Wilde
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM> Существуют также объекты старого стиля (object), на которые распространяется многое из вышесказанного, но все-таки не все.
По поводу "новых" и "старых" стилей, интересно : What is New in the Delphi Compiler — Danny Thorpe
Major Win32 Compiler Work
-Records with Methods
TBlock = record
procedure Foo(I : Integer);
function Bar : TBlock;
private
Data : Integer;
public
property Color : Integer...
end;
-Records don't have inheritance, i.e. no VMT.
-Records can implement interfaces in .NET but not in Win32.
-Operator Overloading for Win32 (.Net already has this)
--Requires value semantics (i.e. Records)
--Same syntax & rules as Delphi .NET
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM> Существуют также объекты старого стиля (object), на которые распространяется многое из вышесказанного, но все-таки не все. Ну и где-нибудь дальше в книжке описать, что это за фича и зачем она нужна.
Поскольку объекты "старого стиля" не должны использоваться при программировании, они изъяты из рассмотрения.
Здравствуйте, Аноним, Вы писали: А>Поскольку объекты "старого стиля" не должны использоваться при программировании, они изъяты из рассмотрения.
Это откуда же такой вывод, что не должны?! Может, ссылочку приведете? И как же тогда прикажете создавать объекты без VMT и без всей RTTIшной шелухи (имею в виду ClassName, ClassType, etc.)?
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Здравствуйте, Аноним, Вы писали: А>>Поскольку объекты "старого стиля" не должны использоваться при программировании, они изъяты из рассмотрения.
SM>Это откуда же такой вывод, что не должны?! Может, ссылочку приведете? И как же тогда прикажете создавать объекты без VMT и без всей RTTIшной шелухи (имею в виду ClassName, ClassType, etc.)?
SM>Slicer
А как же это (из справки D5):
Object types are supported for backward compatibility only. Their use is not recommended.
It is always bad to give advices, but you will be never forgiven for a good one.
Oscar Wilde
Здравствуйте, ramasha, Вы писали:
SM>> Существуют также объекты старого стиля (object), на которые распространяется многое из вышесказанного, но все-таки не все. R>По поводу "новых" и "старых" стилей, интересно : What is New in the Delphi Compiler — Danny Thorpe
R> -Records don't have inheritance, i.e. no VMT. R> -Records can implement interfaces in .NET but not in Win32.
В 2006-м Delphi пообещали сделать методы для записей под Win32..
Re[6]: Программирование на языке Delphi. Глава 3.
От:
Аноним
Дата:
29.11.05 19:11
Оценка:
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Здравствуйте, ekamaloff, Вы писали:
E>>
Object types are supported for backward compatibility only. Their use is not recommended.
SM>Тогда посыпаю голову пеплом. Вот лопухи, record до C++-ного класса так и не дорастили по возможностям, а существующую альтернативу объявили deprecated
Это не недоработка, объектная модель была полностью пересмотрена. Было решено отказаться от value-type объектов. И правильно, иначе теряются все преимущества объектов (расширение типа, виртуальные методы и т.д.). Представьте ситуацию, что объявляется массив из value-type объектов. Вы можете добавить в массив объект производного класса? Вы можете записать такой объект в файл (как вы записываете запись)? Кстати, на платформе .NET value-type объекты отсутствуют. Чувствуется одна и та же рука
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Здравствуйте, ekamaloff, Вы писали:
E>>
Object types are supported for backward compatibility only. Their use is not recommended.
SM>Тогда посыпаю голову пеплом. Вот лопухи, record до C++-ного класса так и не дорастили по возможностям, а существующую альтернативу объявили deprecated
Самое интересное что Object types существуют аж с Dephi 1 и отлично работают. Я например встречал обертку
над GDI+ сделанную с использованием этих типов. Типы Point, Color итд сделаны как object (с служебными методами),
их можно размещать с стеке и не возиться с созданием\удалением.
Hello Аноним, you wrote:
> Это не недоработка, объектная модель была полностью пересмотрена. Было решено отказаться от value-type объектов. И правильно, иначе теряются все преимущества объектов (расширение типа, виртуальные методы и т.д.)
Да ну?
Тогда от куда в Борланд Паскале виртуальные методы?
И наследование там тоже было.
> Представьте ситуацию, что объявляется массив из value-type объектов. Вы можете добавить в массив объект производного класса?
Я вместо этого объявлю массив указателей на объекты. И все у меня получится.
Hello Аноним, you wrote:
> Это не недоработка, объектная модель была полностью пересмотрена. Было решено отказаться от value-type объектов. И правильно, иначе теряются все преимущества объектов (расширение типа, виртуальные методы и т.д.)
Да ну?
Тогда от куда в Борланд Паскале виртуальные методы?
И наследование там тоже было.
> Представьте ситуацию, что объявляется массив из value-type объектов. Вы можете добавить в массив объект производного класса?
Я вместо этого объявлю массив указателей на объекты. И все у меня получится.
Hello Аноним, you wrote:
> Это не недоработка, объектная модель была полностью пересмотрена. Было решено отказаться от value-type объектов. И правильно, иначе теряются все преимущества объектов (расширение типа, виртуальные методы и т.д.)
Да ну?
Тогда от куда в Борланд Паскале виртуальные методы?
И наследование там тоже было.
> Представьте ситуацию, что объявляется массив из value-type объектов. Вы можете добавить в массив объект производного класса?
Я вместо этого объявлю массив указателей на объекты. И все у меня получится.
Hello Аноним, you wrote:
> Это не недоработка, объектная модель была полностью пересмотрена. Было решено отказаться от value-type объектов. И правильно, иначе теряются все преимущества объектов (расширение типа, виртуальные методы и т.д.)
Да ну?
Тогда от куда в Борланд Паскале виртуальные методы?
И наследование там тоже было.
> Представьте ситуацию, что объявляется массив из value-type объектов. Вы можете добавить в массив объект производного класса?
Я вместо этого объявлю массив указателей на объекты. И все у меня получится.
Здравствуйте, Аноним, Вы писали:
А> Кстати, на платформе .NET value-type объекты отсутствуют. Чувствуется одна и та же рука
Советую получше ознакомиться с платформой .NET Ключевое слово "value types". Тамошние структуры допускают наследование (хотя полиморфизм ограничен) и инкапсуляцию (могут содержать вместе с данными и методы). Как и old-style objects. Чего часто и не хватает в дельийских record'ах. Имхо, это недоработка. Если бы в дельфях отказались от old-объектов, но улучшили структуры, я бы не жаловался. А так — от одной альтернативы призывают воздерживаться, а другую не обеспечивают.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Аноним, Вы писали:
А>Это хорошо известно. Все-таки речь шла не о структурах, а о class instances. Ключевой момент — наличие VMT среди полей объекта.
Которое как раз не всегда желательно. Ну и плюс хранение objects в "boxed"-виде, как записей.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, ramasha, Вы писали:
R>-Records don't have inheritance, i.e. no VMT.
Нет VMT <> нет наследования. Правда, "нет VMT" + "нет интерфейсов" = "нет полиморфизма", но наследование уже имевшихся в предке методов все еще возможно. Как фактически обстоит дело в D2006, не знаю.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Slicer [Mirkwood], Вы писали:
R>>-Records don't have inheritance, i.e. no VMT. SM>Нет VMT <> нет наследования.
Действительно, я это упустил.
Я перевел так: Записи не наследуются т.е. нет VMT. Если я правильно перевел, непонятно почему Danny так написал ?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Программирование на языке Delphi. Глава 3.
От:
Аноним
Дата:
02.12.05 17:05
Оценка:
Здравствуйте, Denis_TST, Вы писали:
D_T>Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>>Здравствуйте, ekamaloff, Вы писали:
E>>>
Object types are supported for backward compatibility only. Their use is not recommended.
SM>>Тогда посыпаю голову пеплом. Вот лопухи, record до C++-ного класса так и не дорастили по возможностям, а существующую альтернативу объявили deprecated D_T>Самое интересное что Object types существуют аж с Dephi 1 и отлично работают. Я например встречал обертку D_T>над GDI+ сделанную с использованием этих типов. Типы Point, Color итд сделаны как object (с служебными методами), D_T>их можно размещать с стеке и не возиться с созданием\удалением.
D_T>Почему их похоронили совершенно не понятно
Старая модель объектов нарушала концептуальную целостность языка программирования.
var
X, Y: T;
begin
...
X := Y;
...
end;
В том случае, если X и Y — value-type objects, непонятно, как должен сработать оператор присваивания (например, не понятно, должно ли выполниться копирование указателя VMT). Проектировщики языка сделали ошибку, но у них хватило смелости ее признать и исправить. Это стало возможным благодаря тому, что не существовало стандарта на язык Borland Pascal (иногда отсутствие стандарта играет положительную роль).
Здравствуйте, Аноним, Вы писали:
А>Старая модель объектов нарушала концептуальную целостность языка программирования.
А>var А> X, Y: T; А>begin А> ... А> X := Y; А> ... А>end;
А>В том случае, если X и Y — value-type objects, непонятно, как должен сработать оператор присваивания (например, не понятно, должно ли выполниться копирование указателя VMT).
Но позвольте — эта операция, тем не менее, выполнялась четко определенным образом Причем присуща она не только BP, но и C++...
Впрочем, разговор ушел в сторону. Предлагаю отделить ветку и отправить в holy wars или еще куда. Факт тот, что борманы уже объявили это дело deprecated, а после драки кулаками не машут.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
