Comments 34
Да, замечательная возможность, уже вовсю использую. Раньше приходилось реализовать специальный интерфейс с методом возвращающим ссылку на объект, сейчас стало все проще… Еще понравилось, что в Exit теперь можно результат функции аргументом передать.
Гениально! А нафига вам интерфейсы тогда, если нужна ссыла на объект? :) Нет, мне положительно нравятся такие вот извращения: сначала всеми силами лезем в абстракции, а потом резко ищем приземлённости и конкретики. Костыльно-ориентированное программирование во плоти.
Вот пример из практики. У меня интерфейсы торчат наружу для Javascript-а, соответственно они все от IDispatch и работают только с типами данных поддерживающими автоматизацию. Вот я сделал объект — битмап, выставил наружу только необходимые методы для манипуляции скриптом и хочу реализовать метод отрисовки одного битмапа на другом. Самое простое это как раз проверить аргумент метода на IS, а потом привести через AS и выполнить работу на низком уровне, чем городить новый интерфейс для получения необходимых для выполнения работы данных.
По поводу архитектуры — ваша правда, все это как бы идеологически неправильно, но в реальном программировании нужно бывает чтобы это работало здесь и сейчас и как бы ты архитектуру не «вылизывал» — изъяны будут. Идеальная архитектура недостижима — как коммунизм… :)
По поводу архитектуры — ваша правда, все это как бы идеологически неправильно, но в реальном программировании нужно бывает чтобы это работало здесь и сейчас и как бы ты архитектуру не «вылизывал» — изъяны будут. Идеальная архитектура недостижима — как коммунизм… :)
Потому что интерфейс, в отличие от класса не несет в себе реализации, а несет набор функций, которые можно как угодно реализовать. Что прибавляет гибкости, и позволяет код сделать более аккуратным.
Вот вам кстати простейший пример: программе надо периодичеки сохранять какие-то свои настройки. Для этого нам нужно 2 метода у объекта: saveSetting(name, value) и getSetting(name). Допустим, изначально решено сохранять их на диск и сделать для этого класс допустим diskStorage. А завтра вдруг выясняется, что программу усложнили, и теперь в некоторых версиях должно быть сохранение на диск, а в другой — допустим в реестр, или в БД. Как вы теперь это реализуете без интерфейсов?
Вообще-то использование объекта — это обращение к его публичному интерфейсу.
И непонятно, почему у публичного интерфейса должно быть меньше прав чем у выделенных.
Другое дело, что ссылка на объект — это привязка к Delphi, но недостаток здесь не в исторических костылях — классы вводили, не заботясь об их переносимости из языка в язык.
И непонятно, почему у публичного интерфейса должно быть меньше прав чем у выделенных.
Другое дело, что ссылка на объект — это привязка к Delphi, но недостаток здесь не в исторических костылях — классы вводили, не заботясь об их переносимости из языка в язык.
Спасибо большое за статьи по Delphi. Может кто подскажет литературу для начинающего программера..?)
Литературы по программированию полный интернет. ТЕбе надо конкретно что? Алгоритмы, синтаксис языка, что такое ООП и т.д.
может начинающему стоит обратить внимание на другие языки?
Книжки Архангельского поищи. Но вообще обучаться программированию лучше с чего-нибудь попроще, или наоборот — сразу с функциональщины.
UFO just landed and posted this here
Если в большей части кода использование обобщённое, но в некотрых местах зависимое от реализации, это свидетельствует о плохой архитектуре. Постараюсь показать альтернативы на примере потока ввода-вывода (I/O stream). Итак, есть несколько стандартный путей:
1) Большой интерфейс. Пустые реализации ненужных методов. Например, не для всех потоков ввода-вывода имеет смысл операция Flush(), но она может присутствовать в интерфейсе всегда. Для TCP/IP сокета реализация может быть пустой, а для файла — нет.
Плюс в унифицированности использования.
Минус в сложности отладки, так как редко реализуемые методы зачастую забывают вызвать. Скажем, если основной используемый поток сокетный, то забывают вызвать Flush() и при аварийном сбое в файл не попадают последние записи.
2) Маленькие интерфейсы. Переразбиение большого интерфейса на несколько. Например, IInputStream, IOutputStream, IFlushableStream.
Плюс в минимизации методов с пустой реализацией. Кроме того, реализация интерфейсов декларирует поддерживаемую функциональность.
Минус в дублировании. У файла открытого как на запись, так и на чтение будет две длины: от IInputStream и от IOutputStream, две текущих позиции и т.д. Кроме того, всегда существует множество способов разбить большой интерфейс на мелкие. Разбиение: IStream, IDimensionalStream, ISeekableStream не менее правомерно. В общем случае разбиение отражает сценарии использования и не может быть универсальным.
3) Большой интерфейс с метаинформацией. Те же пустые реализации ненужных методов, но разбавленные вспомогательными маркерами реализуемой функциональности: CanRead, CanWrite, CanFlush, CanSeek.
Плюс в унифицированности использования.
Минус в том, что это в некоторой степени самообман. Хотя кажется, что решается архитектурная проблема варианта №2, так как поиск оптимального разбиения функциональности по интерфейсам больше не актуален, в действительности добиться от вызывающей стороны корректной проверки реализуемой функциональности через маркеры довольно сложно.
4) Использование патерна Декоратор. Вместо декларации метода в интерфейсе создать реализацию выполняющую работу метода в рамках вызова других методов. Например, создать помимо очевидной реализации FileStream, отдельную реализацию-обёртку LogFileStream, которая сама вызывает Flush() после каждого Write().
Плюс в полной прозрачности для вызывающей стороны.
Минус в узкости области применения, так как Flush после Write это конкретный фиксированный сценарий. Кроме того, количество реализаций интерфейса растёт существенно быстрее, что так же может оказаться минусом. Немаловажно так же то, что классы должны быть дружественны к оборачиванию. Например в примере выше, должна быть возможность получить в обёртке значение дескриптора файла.
Исходя их того, куда движется программирование, а оно движется в сторону сервис-провайдеров, мировая общественность за вариант №2.
1) Большой интерфейс. Пустые реализации ненужных методов. Например, не для всех потоков ввода-вывода имеет смысл операция Flush(), но она может присутствовать в интерфейсе всегда. Для TCP/IP сокета реализация может быть пустой, а для файла — нет.
Плюс в унифицированности использования.
Минус в сложности отладки, так как редко реализуемые методы зачастую забывают вызвать. Скажем, если основной используемый поток сокетный, то забывают вызвать Flush() и при аварийном сбое в файл не попадают последние записи.
2) Маленькие интерфейсы. Переразбиение большого интерфейса на несколько. Например, IInputStream, IOutputStream, IFlushableStream.
Плюс в минимизации методов с пустой реализацией. Кроме того, реализация интерфейсов декларирует поддерживаемую функциональность.
Минус в дублировании. У файла открытого как на запись, так и на чтение будет две длины: от IInputStream и от IOutputStream, две текущих позиции и т.д. Кроме того, всегда существует множество способов разбить большой интерфейс на мелкие. Разбиение: IStream, IDimensionalStream, ISeekableStream не менее правомерно. В общем случае разбиение отражает сценарии использования и не может быть универсальным.
3) Большой интерфейс с метаинформацией. Те же пустые реализации ненужных методов, но разбавленные вспомогательными маркерами реализуемой функциональности: CanRead, CanWrite, CanFlush, CanSeek.
Плюс в унифицированности использования.
Минус в том, что это в некоторой степени самообман. Хотя кажется, что решается архитектурная проблема варианта №2, так как поиск оптимального разбиения функциональности по интерфейсам больше не актуален, в действительности добиться от вызывающей стороны корректной проверки реализуемой функциональности через маркеры довольно сложно.
4) Использование патерна Декоратор. Вместо декларации метода в интерфейсе создать реализацию выполняющую работу метода в рамках вызова других методов. Например, создать помимо очевидной реализации FileStream, отдельную реализацию-обёртку LogFileStream, которая сама вызывает Flush() после каждого Write().
Плюс в полной прозрачности для вызывающей стороны.
Минус в узкости области применения, так как Flush после Write это конкретный фиксированный сценарий. Кроме того, количество реализаций интерфейса растёт существенно быстрее, что так же может оказаться минусом. Немаловажно так же то, что классы должны быть дружественны к оборачиванию. Например в примере выше, должна быть возможность получить в обёртке значение дескриптора файла.
Исходя их того, куда движется программирование, а оно движется в сторону сервис-провайдеров, мировая общественность за вариант №2.
1) Single Responsibility Principle и Interface Segregation Principle
2) Дублирования не будет, если сделать отдельный универсальный класс Stream, которым будут пользоваться для своих целей реализации указанных интерфейсов. Интерфейсы отражают сценарии использования, но реализация следовать этому принципу не обязана ибо как раз благодаря интерфейсам от неё никто не зависит!
3) Tell, don't ask — не спрашивайте (CanRead? CanWrite?), а указывайте.
4) Опять же SRP (конкретные сценарии — это хорошо, если сценарий реализован и работает — не думаем больше о нём и сосредотачиваемся на других частях программы) и Tell, don't ask (не спрашивайте дескриптор, а сразу указывайте, что нужно делать (вызывайте метод) — тем самым явно обозначая своё намерение).
А вообще, вот полезный набор практик: SOLID.
2) Дублирования не будет, если сделать отдельный универсальный класс Stream, которым будут пользоваться для своих целей реализации указанных интерфейсов. Интерфейсы отражают сценарии использования, но реализация следовать этому принципу не обязана ибо как раз благодаря интерфейсам от неё никто не зависит!
3) Tell, don't ask — не спрашивайте (CanRead? CanWrite?), а указывайте.
4) Опять же SRP (конкретные сценарии — это хорошо, если сценарий реализован и работает — не думаем больше о нём и сосредотачиваемся на других частях программы) и Tell, don't ask (не спрашивайте дескриптор, а сразу указывайте, что нужно делать (вызывайте метод) — тем самым явно обозначая своё намерение).
А вообще, вот полезный набор практик: SOLID.
1) Беда в том, что responsibility штукенция субъективная. Для кого-то responsibility это работа с файлом в целом, а для кого-то чтение файла и запись файла разные responsibility.
Можно сказать с уверенностью, чтение файлов и расчёт числа пи уже не single responsibility, и только. То есть принцип, конечно, верный, но чёткого критерия нет и применяется он на уровне опыта и интуиции.
Правило «no client should be forced to depend on methods it does not use» в примере не нарушено. Наличие неиспользуемого Flush() не обязывает (forced to depend) писать дополнительный код или иначе писать код использующий другие методы. Так что ISP немного не про то.
2) Ну вот в стандартной библиотеке Си++ дублирование есть: istream, ostream содержат множество похожих методов. Правда в Си++ есть множественное наследование, что спасает.
3) Смотри класс Stream из .Net. Без множественного наследования, проблемы дублирования из примера №2 становятся неразрешимыми. В итоге имеем пресловутые маркеры CanRead, CanWrite.
Можно сказать с уверенностью, чтение файлов и расчёт числа пи уже не single responsibility, и только. То есть принцип, конечно, верный, но чёткого критерия нет и применяется он на уровне опыта и интуиции.
Правило «no client should be forced to depend on methods it does not use» в примере не нарушено. Наличие неиспользуемого Flush() не обязывает (forced to depend) писать дополнительный код или иначе писать код использующий другие методы. Так что ISP немного не про то.
2) Ну вот в стандартной библиотеке Си++ дублирование есть: istream, ostream содержат множество похожих методов. Правда в Си++ есть множественное наследование, что спасает.
3) Смотри класс Stream из .Net. Без множественного наследования, проблемы дублирования из примера №2 становятся неразрешимыми. В итоге имеем пресловутые маркеры CanRead, CanWrite.
Такой вопрос: это в Delphi for .net, или в native-коде тоже поддерживается?
Эх, Deplhi, конечно, строгий язык, удобочитаемый код итд, но я не могу понять, почему раньше тот код с явным кастом не компилировался. Я так понимаю, в предыдущих версиях приходилось работать через промежуточный каст к Object'у?
//
Мне кажется, здесь действительно лучше всего — позиция Java и C#, в котором код, содержащий кастинг ссылочных объектов, будет в любом случае скомпилирован, а корректность кастинга проверяется в рантайме. Если уж нужна строгость и полный контроль за тем, что происходит — то лучше смотреть в сторону С++, где есть разные типы кастов (в данном случае, наиболее подходящим выбором будет dynamic_cast<ImplementationPointer*>.
//
Мне кажется, здесь действительно лучше всего — позиция Java и C#, в котором код, содержащий кастинг ссылочных объектов, будет в любом случае скомпилирован, а корректность кастинга проверяется в рантайме. Если уж нужна строгость и полный контроль за тем, что происходит — то лучше смотреть в сторону С++, где есть разные типы кастов (в данном случае, наиболее подходящим выбором будет dynamic_cast<ImplementationPointer*>.
Эх, Deplhi, конечно, строгий язык, удобочитаемый код итд, но я не могу понять, почему раньше тот код с явным кастом не компилировался.
А как он компилироваться мог? TMyClass() весьма низкоуровневое приведение типов, просто указатель одного типа приводится к другому типу. Если мы говорим о наследовании, то таблица виртуальных методов наследника включает в себя таблицу предка, поэтому все работает так, как надо.
TMyClass(object1) приводит указатель одного типа к указателю другого. object1 — указатель на структуру класса, причем по смещению 0 в этой структуре находится указатель на VMT. Таким образом, при выполнении TMyClass(object1).Bar если метод Bar — виртуальный, произойдет чтение адреса VMT структуры object1, и чтение адреса Bar по некоему смещению от начала VMT.
Если бы было так: (MyInterface as TMyClass).Bar было бы логично, а зачем такой синтаксис — непонятно.
В дельфи тоже есть разные типы явных кастов. Статический — «имятипа(выражение)» и динамический «выражение as имятипа».
Они изобрели dynamic_cast (qobject_cast)?
Необходимость получения из интерфейса указателя на объект, его реализующий — свидетельствует о проблемах в проектировании.
Смысл интерфейса в частности в том, что мы не знаем и не должны знать, какой именно объект скрывается за ним.
Смысл интерфейса в частности в том, что мы не знаем и не должны знать, какой именно объект скрывается за ним.
Вот потому, автор то и пишет, что возможность эта достаточно спорная. Кому-то сгодиться ведь, нашлись же люди выше.
Не обязательно это проблема в проектировании — нововведением собственный публичный интерфейс класса всего лишь уравнивается в правах с выделенным, прямого доступа к данным объекта указатель не дает, следовательно инкапсуляцию не нарушает.
Просто для межмодульного взаимодействия она не годится, так как в отличие от выделенных интерфейсов Delphi-only. Но это совсем другая проблема.
Просто для межмодульного взаимодействия она не годится, так как в отличие от выделенных интерфейсов Delphi-only. Но это совсем другая проблема.
Укажи список переводчиков. Зря что ли трудились?
Че-то Эмбаркадера совсем задурила… Глядишь, и «Паблика Морозова» стандартизируют, потому что «бывают случаи».
UBbccYnzJGA
Sign up to leave a comment.
Преобразование ссылки на интерфейс для реализации класса в Delphi 2010