Аннотация:
Сейчас преимущества использования объектов очевидны для всех. Однако так было не всегда. Сначала старая гвардия не поняла и не приняла объекты, поэтому они почти 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
