SlideShare a Scribd company logo
1 of 4
Download to read offline
TRABALHO DE

    PROGRAMAÇÃO

      ORIENTADO A

           OBJETO




Prof. Edgar Davidson
Alunos:
  Marco Antônio
  Wanderson Ribeiro
Princípio da Reutilização Comum (CRP)


       Princípio da Reutilização Comum diz que as classes em pacote (package) são
reutilizadas em conjunto e se reutilizar umas das classes em um pacote, estará
reutilizando todas.

       Somente as classes coesas devem ser empacotadas em conjunto. Assim como
em tudo, os pacotes de classes e sua coesão devem ser definidos a partir da perspectiva
do usuário. Se um usuário utiliza um pacote (package), todas as classes do pacote devem
ser reutilizáveis no mesmo contexto. As classes que não estão intimamente relacionados
entre si não devem está no mesmo pacote, então toda vez que houver dependência de
um pacote, haverá dependência de cada classe existente no pacote. É muito importante
decidir quais classes devem ser unidas por um pacote (package). A Inadequada seleção
de classes pode criar dependências indesejáveis e tornar o uso do pacote um pesadelo.

        Exemplo se estiver usando um pacote para cálculos de matrizes, é melhor ter
somente classes relacionadas a essa funcionalidade, caso contrário, estará reavaliando e
redistribuindo, mas do que necessário, gastando assim também mais esforço do que
suficiente.

       Um outro exemplo simples pode ser uma classe container e seus associados
iteradores. Estas classes são reutilizadas juntas devido a estarem estreitamente ligada
uma as outras.

       Ponto Relevante do CRP

       Mesmo usando apenas uma classe dentro do pacote, ainda assim existe uma
dependência, portanto se houver mudança em apenas uma classe do pacote (package),
todo o pacote dever reavaliado e redistribuído.
As figuras abaixo irão ilustrar melhor o principio CRP:

  Classes reutilizadas colaboram com outras classes que são parte de uma
  abstração bem coesa que chamamos de pacotes (package).




  Quando um pacote usa outro é criado então uma dependência entre eles.




  Se dentro do pacote (package) é usado somente uma classe mesmo assim
  haverá uma forte dependência de todo o pacote.




  Cada vez que o pacote (P2) é atualizado, usando o pacote (P1) então (P1)
  deve ser reavaliado e redistribuído.
Conclusão:

      Conforme ficou demonstrado no exemplo e nas ilustrações acima, a desvantagem
do princípio está no forte vinculo das classes do pacote, se for usar somente uma classe
do mesmo terá que usar todo o pacote, empreendendo mais esforço do que é
necessário.

More Related Content

More from Engenharia de Software Ágil

OCP - The Open Close Principle - Princípio aberto/fechado
OCP - The Open Close Principle - Princípio aberto/fechadoOCP - The Open Close Principle - Princípio aberto/fechado
OCP - The Open Close Principle - Princípio aberto/fechadoEngenharia de Software Ágil
 

More from Engenharia de Software Ágil (18)

Acyclic dependencies principle
Acyclic dependencies principleAcyclic dependencies principle
Acyclic dependencies principle
 
Acyclic dependencies principle (adp)
Acyclic dependencies principle  (adp)Acyclic dependencies principle  (adp)
Acyclic dependencies principle (adp)
 
Reuse release equivalence principle
Reuse release equivalence principleReuse release equivalence principle
Reuse release equivalence principle
 
Rep reuse release equivalence principle
Rep reuse release equivalence principleRep reuse release equivalence principle
Rep reuse release equivalence principle
 
OCP - The Open Close Principle - Princípio aberto/fechado
OCP - The Open Close Principle - Princípio aberto/fechadoOCP - The Open Close Principle - Princípio aberto/fechado
OCP - The Open Close Principle - Princípio aberto/fechado
 
Sdp – stable dependencies principles
Sdp – stable dependencies principlesSdp – stable dependencies principles
Sdp – stable dependencies principles
 
Princípio law of demeter
Princípio law of demeterPrincípio law of demeter
Princípio law of demeter
 
Lod law of demeter
Lod law of demeterLod law of demeter
Lod law of demeter
 
Dip the dependency inversion principle
Dip   the dependency inversion principleDip   the dependency inversion principle
Dip the dependency inversion principle
 
Dip the dependency inversion principle
Dip   the dependency inversion principleDip   the dependency inversion principle
Dip the dependency inversion principle
 
Dip the dependency inversion principle
Dip   the dependency inversion principleDip   the dependency inversion principle
Dip the dependency inversion principle
 
(ISP) - Interface Segregation Principle
(ISP)  - Interface Segregation Principle(ISP)  - Interface Segregation Principle
(ISP) - Interface Segregation Principle
 
LSP – The Liskov Substitution Principle
LSP – The Liskov Substitution PrincipleLSP – The Liskov Substitution Principle
LSP – The Liskov Substitution Principle
 
SRP - Single Responsability Principle
SRP - Single Responsability PrincipleSRP - Single Responsability Principle
SRP - Single Responsability Principle
 
Princípio Law Of Demeter (LOD)
Princípio Law Of Demeter (LOD)Princípio Law Of Demeter (LOD)
Princípio Law Of Demeter (LOD)
 
TDD - Test Driven Development
TDD - Test Driven DevelopmentTDD - Test Driven Development
TDD - Test Driven Development
 
FDD
FDDFDD
FDD
 
DDD - Domain Driven Design
DDD - Domain Driven DesignDDD - Domain Driven Design
DDD - Domain Driven Design
 

principio de reutilização comum

  • 1. TRABALHO DE PROGRAMAÇÃO ORIENTADO A OBJETO Prof. Edgar Davidson Alunos: Marco Antônio Wanderson Ribeiro
  • 2. Princípio da Reutilização Comum (CRP) Princípio da Reutilização Comum diz que as classes em pacote (package) são reutilizadas em conjunto e se reutilizar umas das classes em um pacote, estará reutilizando todas. Somente as classes coesas devem ser empacotadas em conjunto. Assim como em tudo, os pacotes de classes e sua coesão devem ser definidos a partir da perspectiva do usuário. Se um usuário utiliza um pacote (package), todas as classes do pacote devem ser reutilizáveis no mesmo contexto. As classes que não estão intimamente relacionados entre si não devem está no mesmo pacote, então toda vez que houver dependência de um pacote, haverá dependência de cada classe existente no pacote. É muito importante decidir quais classes devem ser unidas por um pacote (package). A Inadequada seleção de classes pode criar dependências indesejáveis e tornar o uso do pacote um pesadelo. Exemplo se estiver usando um pacote para cálculos de matrizes, é melhor ter somente classes relacionadas a essa funcionalidade, caso contrário, estará reavaliando e redistribuindo, mas do que necessário, gastando assim também mais esforço do que suficiente. Um outro exemplo simples pode ser uma classe container e seus associados iteradores. Estas classes são reutilizadas juntas devido a estarem estreitamente ligada uma as outras. Ponto Relevante do CRP Mesmo usando apenas uma classe dentro do pacote, ainda assim existe uma dependência, portanto se houver mudança em apenas uma classe do pacote (package), todo o pacote dever reavaliado e redistribuído.
  • 3. As figuras abaixo irão ilustrar melhor o principio CRP: Classes reutilizadas colaboram com outras classes que são parte de uma abstração bem coesa que chamamos de pacotes (package). Quando um pacote usa outro é criado então uma dependência entre eles. Se dentro do pacote (package) é usado somente uma classe mesmo assim haverá uma forte dependência de todo o pacote. Cada vez que o pacote (P2) é atualizado, usando o pacote (P1) então (P1) deve ser reavaliado e redistribuído.
  • 4. Conclusão: Conforme ficou demonstrado no exemplo e nas ilustrações acima, a desvantagem do princípio está no forte vinculo das classes do pacote, se for usar somente uma classe do mesmo terá que usar todo o pacote, empreendendo mais esforço do que é necessário.