do encapsulamento. A dependencia da implementacao herdada tambem prejudica no reuso das classes. As vantagens da Composicao basicamente sao: os objetos sao acessados somente atraves de suas interfaces, sem violar o encapsulamento e proporcionando independencia de implementacao, alem do fato de que, com classes em que um numero pequeno de herancas e usado e temos papeis bem definidos e focados, aumenta-se entao, a capacidade de reutilizacao.As desvantagens da Composicao podem ser: como neste caso a heranca diminuira, e o numero de objetos no sistema aumentara, e consequentemente, a performance do sistema que utiliza a composicao dependera de como sera feito o inter-relacionamento entre esses objetos.Delegacao: E um principio muito importante e que tambem e largamente utilizado nos Padroes de Projetos, se baseia no envolvimento de dois objetos ou mais objetos que visam atender a uma determinada solicitacao (utiliza poderosamente a composicao de objetos).Exemplificando-se tem-se uma classe Window em Rectangle. Em vez de se fazer Window sub-classe de Rectangle (uma Janela e retangular!), ela reutilizaria o comportamento de Rectangle. Em vez de dizer que uma Window e um Rectangle, diremos entao que uma Window possui um comportamento de um Rectangle.A principal vantagem disso e que se Window em tempo de execucao, quiser ter um comportamento de um Circle (circulo), basta utilizar uma instancia de Circle assumindo que ambas tenham o mesmo tipo (interface).Existem duas desvantagens: Um codigo dinamico e altamente parametrizavel e mais dificil de compreender e a performance e comprometida porque definir trocas em tempo de execucao possuem um overhead da troca de contexto antes da execucao propriamente dita.Conclui-se que o uso da delegacao e recomendavel quando a mesma simplificar e nao complicar o projeto. Um exemplo de Padrao para ilustrar esses conceitos: Bridge.Este padrao estrutural do GOF basicamente define um modelo no qual separa o conceito (definido pelas classes a esquerda) das suas implementacoes.A heranca e utilizada nas relacoes entre as classes Abstraction e RefinedAbstraction, na qual uma implementacao do conceito e definida pelo seu tipo. Temos heranca tambem na relacao entre a interface Implementor e suas implementacoes ConcreteImplementorA e ConcreteImplementorB. O proposito disto e dar flexibilidade na relacao entre o conceitos e suas duas formas de implementacoes, configurando assim a relacao de delegacao polimorfica entre as duas estruturas definidas distintamente.A composicao se da justamente nesta relacao de delegacao entre as duas interfaces Abstraction e Implementor, o que nos permite compor N combinacoes de novas abstracoes (conceitos) com N tipos diferentes de comportamentos (implementacoes). Tal definicao nos fornece entao, a granularidade de objetos almejada para este proposito.Podemos concluir entao que, RefinedAbstraction pode invocar metodos, assumindo comportamentos, (representados por sua interface) tanto de ConcreteImplementorA ou ConcreteImplementorB. Bom, neste ponto voce ja deve estar pensando que poderia muito bem fazer esta relacao entre conceito <-> implementacao simplesmente colocando as classes ConcreteImplementorA e ConcreteImplementorB como "herdeiras" de RefinedAbstraction, mas esta falta de separacao te dara algumas dores de cabeca quando voce necessitar incluir mais uma forma de implementacao (ConcreteImplementorC, por exemplo), ja que, para se adequar a isto, teria-se que modificar tambem a RefinedAbstraction, ou seja, o custo de manutencao, em um projeto real,