непереопределённые обстрактные методы

← →
oxffff © (2009-01-15 15:23) [80]

> Alkid © (15.01.09 13:15) [47]
>
> > oxffff © (15.01.09 12:51) [40]
>
> В [29] описана ситуация с неправильно спроектированной структурой
> классов и "хакерский" подход при работе с ней. Данная практика,
> ИМХО, порочна, поскольку является раскладыванием граблей
> на будущее, что бы на них можно было самому потом смачно
> наступить, когда ты уже забудешь про свой гениальный ход.
> Ну или для ближнего своего грабля получится, когда он на
> это напорется.
>
> По сути ты предлагаешь создать объект, который не выполняет
> опубликованного контракта (интерфейса). Это небезопасный
> ход, который требует от тебя постоянно держать в голове
> тот факт, что для данного объекта действует только часть
> интерфейса.

Я же говорю есть разные точки зрения. Жестокая декомпозиция приводит к потере эффективности. Поэтому нужна середина между гибкостью и эффективностью кода, размера приложения.
Мне ничего не стоит в этом классе вынести дополнительно контракт интерфейс(часть функциональности) и работать с ним.
Хотя я разделяю обе точки зрения, считаю что и так плохо и так плохо и в тоже время и так хорошо и так хорошо. :)
В вообщем в зависимости от условий делаю выбор. Самое главное, что есть средство которое это предоставляет.

← →
oxffff © (2009-01-15 15:26) [81]

← →
oxffff © (2009-01-15 15:30) [82]

> Alkid © (15.01.09 14:02) [60]
>
> > Mystic © (15.01.09 13:54) [57]
>
> Я понимаю твою точку зрения, но она напрямую противоречит
> уже заложенной в Дельфи философии на явность всех декларций.
> Overload, override, reintroduce и т.п. Т.е. программист
> явно говорит, что он тут хочет сказать, что бы не вышло
> случайной перегрузки или переопределения. То, что ты предлагаешь
> идёт вразрез с этой философией, по-этому я считаю это недосмотром
> с точки зрения разработчиков языка. Предлагаемый тобой подход
> в бОльшей степени подошёл бы C++, где компилятор без лишних
> деклараций делает выводы о перегрузке/переопределении.

Более того,, а почему бы нам например не поговорить о делегированию реализации через встроенный механизм.
Как компилятор может проверить, что у экземпляра будет инициализирован делегируемый объект.

>
> Собственно говоря, всё это лишний раз подтверждает, что
> дисциплина поддержания идеологической целостности и чистоты
> в Дельфи хромает

А откуда такой далекоидущий вывод?

← →
XentaAbsenta © (2009-01-15 15:53) [83]

> Юрий Зотов © (15.01.09 15:11) [79]
>
> > XentaAbsenta © (15.01.09 14:51) [74]
>
> > В этом случае возможно инстанцирование T1, что недопустимо
> (напр.
> > через ссылку на класс). Выходом может быть ошибка компиляции
> класса
> > T2 c требованием переопределить к виртуальный конструктор
> Create
> > Что в купе с прямым запретом к инстанцированию абстрактных
> классов,
> > приведёт к принципиальной невозможности их инстанцирования.
>
>
> Даже если в T2 перекрыть конструктор, создать экземпляр
> T1 через ссылку на класс все равно будет можно. И на этапе
> компиляции будет невозможно отследить, экземпляр какого
> именно класса создается.

T1, T2, T3 наследники абстрактного T0
во всех их переопределён
constructor Create(var tt : anytype);virtual; abstract;
type TRef = class of T0; var fff : TRef; hhhhh : T0; begin u := Random(4); case (u) of 1 : fff := T1; 2 : fff := T2; else fff := T0; end; hhhhh := fff.Create(u); end.

Действительно проблема имеет быть место. Действительно невозможно определить кого будет истанцировать, но выкинуть эксценшн в
hhhhh := fff.Create(u) можно!

← →
Юрий Зотов © (2009-01-15 16:14) [84]

> XentaAbsenta © (15.01.09 15:53) [83]

> выкинуть эксценшн в hhhhh := fff.Create(u) можно!

Во-первых, это все равно уже будет на этапе исполнения.

Во-вторых, для этого нужно снабдить класс механизмом определения, все ли его абстрактные метды перекрыты. А зачем такое усложнение и дополнительные тормоза нужны, если это уже все равно run-time и при вызове неперекрытого абстрактного метода исключение и без того возникнет?

А если такого вызова реально нет, то и нет никакого криминала - значит и незачем зазря блокировать создание объекта.

Все логично, по-моему. При явном создании экземпляра абстрактного класса компилятор выбрасывает варнинг, а при неявном ошибка обнаруживается в run-time при вызове неперекрытого абстрактного метода.

Вполне разумное решение, IMHO.

← →
Mystic © (2009-01-15 17:49) [85]

> Собственно говоря, всё это лишний раз подтверждает, что
> дисциплина поддержания идеологической целостности и чистоты
> в Дельфи хромает.

Я не демагог, поэтому вопросы идеологической ценности и чистоты меня мало интересуют. Мне надо, чтобы язык позволял мне эффективно решать поставленные задачи. Поэтому я себя несколько неуютно себя чувствую в языках типа Java: хочется поковырять отверткой в ухе, а из-за идеологической целостности сделать это нельзя.

← →
Alkid © (2009-01-15 17:55) [86]

> oxffff © (15.01.09 15:30) [82]
> А откуда такой далекоидущий вывод?

Из наблюдений за языком.

> Mystic © (15.01.09 17:49) [85]
> Я не демагог, поэтому вопросы идеологической ценности и
> чистоты меня мало интересуют. Мне надо, чтобы язык позволял
> мне эффективно решать поставленные задачи. Поэтому я себя
> несколько неуютно себя чувствую в языках типа Java: хочется
> поковырять отверткой в ухе, а из-за идеологической целостности
> сделать это нельзя.

Значит ты апологет "хакерского" подхода к программированию. Такой подход тоже имеет право на существование, но я считаю его неправильным.

← →
oxffff © (2009-01-15 18:38) [87]

> Alkid © (15.01.09 17:55) [86]
>
> > oxffff © (15.01.09 15:30) [82]
> > А откуда такой далекоидущий вывод?
>
> Из наблюдений за языком.

Хотелось услышать конкретные примеры нарушение идеалогической целостности Delphi?
В студию так сказать?

← →
Медвежонок Пятачок © (2009-01-15 18:43) [88]

вся маета от привычки считать возбужденный эксепшен ошибкой.

← →
oxffff © (2009-01-15 18:51) [89]

> Alkid © (15.01.09 17:55) [86]
> > Mystic © (15.01.09 17:49) [85]
...........
>
> Значит ты апологет "хакерского" подхода к программированию.
>

Что это за подход к программированию?
Есть ситуации, когда прямое соблюдение идеалогии делает невозможным производить вполне безобидные операции. И проведение "прямых" манипуляций это вынужденная мера. Развитие концепции языка,
его type theory находится увы не в наших руках.
Поэтому хакерский код - это совсем из другой области.

← →
Mystic © (2009-01-15 19:47) [90]

> Значит ты апологет "хакерского" подхода к программированию.
> Такой подход тоже имеет право на существование, но я считаю
> его неправильным.

Хакерский стиль у меня больше ассоциируется с отсутствием всяких правил. Я сторонник здравого смысла и конкретного подхода к задаче и к каждому проекту. За все время программирования на Delphi я не могу припомнить ни одного случая, чтобы эта реализация абстрактного метода приводила к труднонаходимой ошибке. В случае блока try..except end; без очень веских на то причин, я готов бить канделябром по голове. Но если в системе создается абстрактный класс, то это не самое худшее, что может быть.

Описанная ситуация, что надо помнить о том, что вызов абстрактного метода ведет к исключению ничем не отличается от той, что при обращении к непроинициализированному полю может возникнуть AV, или если не установлено соединение с базой, то выполнение SQL-запроса приведет к исключению, а также если сокет закрыт, то посылать в него что-то бесполезно. И т. д. и т. п.

>Mystic © (15.01.09 19:47) [90]

Полностью поддерживаю.

> Но если в системе создается абстрактный класс, то это не
> самое худшее, что может быть.

Более того не составляет особого труда написать процедуру, которая будет при создании объекта проверять наличие абстрактных методов и информировать у удобном для программиста виде run time.

хакерский подход к программированию не должен сущестовать как класс. Вырубить на корню, а несогласных кадилом по чайнику.
-------------
Он порождает демонов сложности и разрушает целостность проектов. Если хотите - открывайте тему - обосную.

Abstract"ы я выбрал бы только за то, что ворнинги сыплет изрядно! (с) моё

Написал класс, объявил асбтрактных методов. Начинаем писать наследников, хренакс, ворнинг. Спасибо. Забыл. Дописываю.

А если без этого то как? Понятно, что можно, но вопрос удобства разве не важен?

непереопределённые обстрактные методы Найти похожие ветки