Страница 7 из 7

Re: Зачем два механизма ограничений?

СообщениеДобавлено: 30.10.2015 00:09:04
stanilar
скалогрыз писал(а):делаю через общий базвый абстрактный (или пустой) класс.

Когда зависимости удачно спроектированы - это хорошо. Но так получается не всегда. Есть определенный плюс в том, что интерфейсы позволяют сделать надстройку над уже существующими отношениями классов.

скалогрыз писал(а):1 интерфейc обслуживает 1 класс.

Разговор изначально зашел про новую языковую возможность. У меня просто появилась мысль о том, что в языке уже все есть.

Re: Зачем два механизма ограничений?

СообщениеДобавлено: 30.10.2015 00:12:28
скалогрыз
stanilar писал(а):Разговор изначально зашел про новую языковую возможность. У меня просто появилась мысль о том, что в языке уже все есть.

Интерфейсы это подобный функционал, но никак не идентичный желаемому.

Re: Зачем два механизма ограничений?

СообщениеДобавлено: 30.10.2015 00:23:04
stanilar
скалогрыз писал(а):Интерфейсы это подобный функционал, но никак не идентичный желаемому.

Вместе с остальными языковыми возможностями, они дополняют язык до нужного соответствия.

Re: Зачем два механизма ограничений?

СообщениеДобавлено: 30.10.2015 01:33:55
скалогрыз
stanilar писал(а):Вместе с остальными языковыми возможностями, они дополняют язык до нужного соответствия.

смысл изменения в том, чтобы минимизировать использование различных языковых возможностей.

Re: Зачем два механизма ограничений?

СообщениеДобавлено: 30.10.2015 02:05:31
stanilar
Есть языковые конструкции, от которых нельзя отказаться. Если вместе с ними, язык содержит все необходимые возможности, то нет острой необходимости плодить сущности.

Re: Зачем два механизма ограничений?

СообщениеДобавлено: 30.10.2015 05:43:48
скалогрыз
stanilar писал(а):Есть языковые конструкции, от которых нельзя отказаться. Если вместе с ними, язык содержит все необходимые возможности, то нет острой необходимости плодить сущности.

от языковых конструкций никто не предлагает отказатся. Новые сущности не предлагают плодить.
Наоборот, предлагают уточнить описание существующих и сделать его более модульным.
При этом 100% обратная совместимость. Т.е. все private можно оставить в interface.

Например, почему в С++, описание класса должно идти целиком?
Потому что в С++ классы могут легко располагатся в стеке, и полный размер должен быть известен каждому кусочку кода, на момент компиляции.
В Паскале, размер класса нужен только на момент исполнения, так что скрытую "private" часть класса, можно спрятать в implementation. (Но даже в этом случае, размер экземпляра будет известен на момент компиляции)

Второй пример, почему в С++, описание класса должно идти целиком.
Потому что в С++ есть "друзья" которые имеют доступ к приватным полям класса, естественно они должны знать о приватных полях.
В Паскале "друзей" нет, а есть область видимости модуля. Весь код, находящийся в том же модуле имеет доступ к "private" секции. Весь модуль - "друг". Если "private" поля вынести в implementation, область видимости это никак не нарушит.

Re: Зачем два механизма ограничений?

СообщениеДобавлено: 30.10.2015 08:39:36
Mikhail
Дож писал(а):Да ладно? :)

Проще так, если уж на то пошло
Код: Выделить всё
PInterface = ^TInterface;
TInterface = record
obj: pointer;
Metod1: procedure (AObj: pointer; ...);
Metod2: procedure (AObj: pointer; ...);
...
end;

Ну а вообще, я о поддержке в языке говорил. :|

Добавлено спустя 3 минуты 5 секунд:
скалогрыз писал(а):Второй пример, почему в С++, описание класса должно идти целиком.

По тем же причинам что и в Паскале, нет никаких проблем сделать иначе.

Re: Зачем два механизма ограничений?

СообщениеДобавлено: 30.10.2015 16:24:12
скалогрыз
Mikhail писал(а):По тем же причинам что и в Паскале, нет никаких проблем сделать иначе.

а вот иначе, в С++ сделать просто невозможно, из-за структуры языка. Ибо всё что использует .c/.cpp должно быть где-то описано в header-е.
В Си++ модулей нет, как и области видимости модулей.

Re: Зачем два механизма ограничений?

СообщениеДобавлено: 31.10.2015 08:48:34
daesher
скалогрыз писал(а):а вот иначе, в С++ сделать просто невозможно, из-за структуры языка. Ибо всё что использует .c/.cpp должно быть где-то описано в header-е.
В Си++ модулей нет, как и области видимости модулей.

Вот о чём и речь (хотя сишные .h - та ещё проблема).
В общем, в паскале есть аналогия - всё, что используют другие модули, должно быть описано где-то в части interface.