Há uma grande diferença entre uma linguagem orientada a objeto e um código orientado a objeto. É perfeitamente possível escrever um código procedural mesmo usando uma linguagem orientada a objeto.
Tá, mas o que é um código procedural?
Um código procedural é aquele onde comportamentos são criados dentro de métodos/funções (também conhecidos como procedures) e tem sua execução por meio do encadeamento de chamadas destas. Valores relacionados a esses comportamentos são passados como parâmetros e retornados de acordo com a necessidade causando a pulverização do controle do estado desses valores e das regras de negócio que atuam sobre esse estado em diversos pontos diferentes.
O tipo de design procedural não é necessariamente ruim quando se tem consciência do que se esta fazendo. Martin Fowler em seu livro Patterns of Enterprise Application Architecture trata sobre essa abordagem procedural ao falar sobre Transactions Scripts, uma das diferentes maneiras que temos de lidar com regras de negócio.
Qual a diferença de um design procedural e um orientado a objeto?
“Qual a diferença entre o charme e o funk? Um anda bonito e outro elegante!” 🎶
MC Markinhos & MC Dollores
Um design procedural não preza pelas características do que é um objeto. Um objeto é uma estrutura que possui dados/propriedades e comportamento/ações, e em um código procedural a tendência é que essas coisas estejam separadas dada a sua natureza de que propriedades e comportamentos estejam espalhadas em diferentes procedures. Esse modelo que separa dados e comportamentos é chamado de Modelo Anêmico.
“Um objeto é uma estrutura que possui dados e ações.”
A orientação a objetos por sua vez gira entorno da junção de dados e comportamentos. Os dados são encapsulados para preservar o estado interno do objeto e os comportamentos que alteram esse estado interno, mediante regras estabelecidas (as regras de negócio) são expostos.
Encapsu o quê??? 💊
O termo que se refere a encapsulamento que apareceu no parágrafo anterior merece uma explicação.
Você não gostaria que um vizinho seu tenha a capacidade mudar as coisas de lugar dentro da sua casa não é? As suas classes também não gostam!
Encapsulamento é a proteção dos dados internos de um objeto. É implementado por meio do correto uso de modificadores de acesso (public, private, protected, default).
Entender bem essa relação entre dados encapsulados e comportamentos expostos que atuam sobre esses dados é essencial para alcançar um design com baixo acoplamento.
Acoplamento, pra que te quero?
Os objetos se relacionam por meio de diversos tipos de relacionamentos diferentes: associação, dependência, especialização, etc... Para se relacionar os objetos precisam se conhecer e isso não é um problema. Na verdade é necessário.
“Acoplamento é intimidade.”
Rodrigo Branas
O problema se dá quando há intimidade nesse relacionamento. Quando os objetos se conhecem em profundidade.
Isso acontece quando em relacionamento entre objetos um conhece as características internas (que deveriam estar encapsuladas) do outro. Caso alguma dessas características internas seja alterada todos os objetos que conhecem (dependem dessa característica) serão quebrados. O acoplamento cria um design de código frágil.
Acoplamento não é bom. Deve ser reduzido ao mínimo possível. Para isso o encapsulamento de propriedades e a exposição cuidadosa de comportamentos deve ser compreendida e aplicada de forma intencional em nosso código. Aplicando esses conceitos damos os primeiros passos para um código orientado a objeto.
Top comments (0)