Да, но это не то же самое. Нельзя взять какой–нибудь базовый кокласс, как–нибудь без проблем агрегировать его, добавить своих функций и использовать как аргумент метода, ожидающий предка (а не интерфейс предка). На одних интерфейсах всего не сделаешь, часто нужно, чтобы полученный объект имел не только фиксированный интерфейс, но и особенность реализации внутри себя. Ну, скажем, нельзя реализовать какой–нибудь не предназначенный для этого интерфейс Office и передать этот фальшивый объект настоящему объекту Office как аргумент. Или, если написать COM–версию ASIO, то рано или поздно дело дойдёт до select(), и потребуются OS–специфичная информация.
При наследовании предок управляет тем, какие интерфейсы будут у потомка, и набор этих интерфейсов может измениться без участия потомка. При агрегации только контейнер единолично решает, какой набор интерфейсов он поддерживает, реализуя сам или делегируя одному из агрегированных объектов. Даже, если переписать эту логику на обратную: все интерфейсы, которые мы не знаем, направлять на делегацию внутреннему объекту, среди этих неизвестных интерфейсов может оказаться следующая версия интерфейса объекта, и в этом случае нужно что–то сделать, чтобы старые методы этого неизвестного интерфейса обрабатывались контейнером. Это можно сделать при помощи кооперации со стороны внутреннего объекта. Наверное, ничего неразрешимого, но дело в том, что это не является продуманным вариантом использования COM, и, если работать в этом направлении, то будет написан новый код, который частью COM не будет, и, учитывая все уровни косвенности, результат будет хуже, чем если с самого начала делать объектную систему, поддерживающую весь набор трансформаций.
NAT тоже ограничен количеством портов (65535) на IP. 10-15 лет? Вряд ли.
Ну хотя, если создать симметричный NAT, максимально упаковывающий юзеров, в том числе повторно использующий исходящие порты для разных юзеров и разных серверов, можно ещё продлить жизнь ненадолго. Уверен, пользовалели Teredo, TeamViewer, игроки, использовавшие ранее Hamachi, да просто p2p'шники, по достоинству оценят симметричный NAT, уходя к конкурентам.
Мне как выход нравится автоматическая настройка IPv6 поверх IPv4. Например, вот есть сейчас в инсталляторах Яндекс.Бары не очень нужные, а почему бы не делать таким же образом конфигурацию IPv6?
Модуль для InnoSetup и других инсталляторов оценит IPv4 и IPv6 connectivity, попробует разные варианты, в том числе 6to4 и Teredo, и оставит включенными те, которые работают.
И, по–хорошему, те же действия роутер должен делать для Teredo и 6to4 (если полученный IPv4 не серый). Предположительно, доступ к другим Teredo узлам будет быстрее через Teredo, чем через нативный IPv6, и аналогично с 6to4.
Далее, у роутеров могут быть какие–то свои базы автонастройки 6rd для провайдеров типа ТТК–ЗС. Получили IPv4, взглянули на него, узнали, что у этого провайдера есть 6rd, настроили 6rd.
Роутер должен через PPPoE, RA или DHCPv6 получить от провайдера настройки для себя, сделать на их основе настройки для LAN и начать анонсить их в LAN по DHCPv6 и RA.
Если такое будет, то рано или поздно мы упадём в пропасть. К примеру, человек досрочно выписался из психбольницы и имеет возможность занять место в госдуме. Он пришёл на работу, написал закон и произвёл переворот, не выходя из Кремля
При наследовании предок управляет тем, какие интерфейсы будут у потомка, и набор этих интерфейсов может измениться без участия потомка. При агрегации только контейнер единолично решает, какой набор интерфейсов он поддерживает, реализуя сам или делегируя одному из агрегированных объектов. Даже, если переписать эту логику на обратную: все интерфейсы, которые мы не знаем, направлять на делегацию внутреннему объекту, среди этих неизвестных интерфейсов может оказаться следующая версия интерфейса объекта, и в этом случае нужно что–то сделать, чтобы старые методы этого неизвестного интерфейса обрабатывались контейнером. Это можно сделать при помощи кооперации со стороны внутреннего объекта. Наверное, ничего неразрешимого, но дело в том, что это не является продуманным вариантом использования COM, и, если работать в этом направлении, то будет написан новый код, который частью COM не будет, и, учитывая все уровни косвенности, результат будет хуже, чем если с самого начала делать объектную систему, поддерживающую весь набор трансформаций.
Ну хотя, если создать симметричный NAT, максимально упаковывающий юзеров, в том числе повторно использующий исходящие порты для разных юзеров и разных серверов, можно ещё продлить жизнь ненадолго. Уверен, пользовалели Teredo, TeamViewer, игроки, использовавшие ранее Hamachi, да просто p2p'шники, по достоинству оценят симметричный NAT, уходя к конкурентам.
Мне как выход нравится автоматическая настройка IPv6 поверх IPv4. Например, вот есть сейчас в инсталляторах Яндекс.Бары не очень нужные, а почему бы не делать таким же образом конфигурацию IPv6?
Модуль для InnoSetup и других инсталляторов оценит IPv4 и IPv6 connectivity, попробует разные варианты, в том числе 6to4 и Teredo, и оставит включенными те, которые работают.
Далее, у роутеров могут быть какие–то свои базы автонастройки 6rd для провайдеров типа ТТК–ЗС. Получили IPv4, взглянули на него, узнали, что у этого провайдера есть 6rd, настроили 6rd.