Представь объект дом. Есть у него как бы внутренние объекты которые не наследуют его. например провода, они ведь ни чего общего с домом не имеют. Но проводам нужна какая то информацию о доме, например где у него проложены кабель каналы. Что бы дать такую информацию проводам приходиться делать методы дающие эту информацию публичными. Проблема в том что объект человек который будет использовать объект дом видеть объект с кучей доступных ему публичных методов которые для него не предназначены, например та же инфра про кабель каналы. Это само собой плохо так как изначально планировалось, что у объекта дом будет гораздо меньше публичных методов и он будет, что-то вроде черного ящика, а не получается так как внутренним объектам нужна инфра и им не откуда ее получит кроме как через публичные методы дома. Что я делаю не так?
Внутренними объектами здесь я называю экземпляры классов хранящихся внутри базового класса, но ни как не связанные с ним через наследования. В моем примере это провода, которые являются частью дома, но с другой стороны, ни имеет, ни какого отношения к дому.

Пример для наглядности 

Паттерны Composite и Bridge в помощь.
Мостом можно абстрагироваться от "клиента" полностью (хотя мост навряд ли то самое, но может содержать интерфейсы для работы с внутренними конкретными объектами), композицией создать композиционный объект (сори  за тавтологию), в Вашем случае "Дом".

Sentox, 
Спасибо, но к сожалению мне не удалось понять как мне могут помочь Composite и Bridge. На другом форуме посоветовали Proxy вот он действительно помог, решение конечно не смое красивое но хоть что-то.

Паттерн композит нужен когда есть составной объект с интерфейсами доступа  (не использования!) к внутренним объектам. Паттерн мост обеспечивает интерфейсами для работы с составным "абстрактным" объектом как с чем то единым целым, эти два паттерна со своими интерфейсами как раз и описывают составной объект, который инкапсулирует внутреннюю логику работы со своими внутренними объектами. То есть класс базового объекта будет имплементировать два различных интерфейса, что даст большую гибкость.
Так что здесь только нужно подумать что конкретно Вам нужно на уровне объектов. То что Вы описали выше называется составным объектом но никак не прокси. Прокси можно было бы использовать для этого составного (громоздкого) объекта если бы у Вас было бы несколько типов их, например: Дом - котедж или маленький домашний, строение завода (цех) и т.д. Тогда прокси можно было бы использовать как прослойка для незаметной работы с ДОМОМ , но ни как с его составными деталями.
Кстати прокси реально не о том:



Это сообщение отредактировал(а) Sentox - 27.11.2011, 20:40