10

Regras
da
da
Programação
Programação
Orientada aa Objetos
Orientada Objetos
por
Marcos Douglas B. dos Santos

Versão 1.1

© 2016 Delfire
www.ObjectPascalProgramming.com
Todos os direitos reservados
1 Programe
Programe para
não
não para
para uma
para uma
uma Interface,
Interface,
uma Implementação
Implementação

Essa talvez seja a Regra mais difundida, porém a menos utilizada.

Você deve evitar o acoplamento entre as classes a todo custo e a melhor maneira de fazer
isso é utilizando Interfaces.

"Nunca utilize classes concretas para definir o tipo

das variáveis, atributos e argumentos dos métodos"

Suas Classes não deveriam estar conectadas entre si diretamente, somente através de
Interfaces.

Toda Classe existente em sua aplicação deverá implementar uma Interface que representa
uma entidade, criatura ou qualquer coisa fora do contexto do programa.

Composição, Agregação e qualquer interação entre Objetos, deverão ser definidas somente
entre Interfaces.

© 2016 Delfire
www.ObjectPascalProgramming.com
Todos os direitos reservados
 Favoreça
Favoreça aa Composição
Composição de
de Objetos
Objetos
2
ao
ao invés
invés da
da Herança
Herança de
de Classes
Classes

Composição, no sentido de Interação entre Objetos, é a Chave para a Programação

Orientada a Objetos.

Herança é o mal, na maioria das vezes.

É extremamente difícil construir uma árvore de herança de Classes sem quebrar o

encapsulamento, redefinir ou ocultar comportamentos de classes superiores.

"Definiram Herança como um dos pilares da

Orientação a Objetos... uma pena, pois a Composição
entre Objetos é um conceito muito mais importante"

Nunca defina suas Classes baseadas em Herança apenas para reutilizar código de Classes
superiores.

Herança define um Conceito abstrato sobre o que uma Classe é, não o que ela faz.

Composição de Classes define Comportamento.

© 2016 Delfire
www.ObjectPascalProgramming.com
Todos os direitos reservados
 3 Objetos
Objetos devem
apenas
devem Implementar
apenas uma
Implementar
uma Responsabilidade
Responsabilidade

Todo Objeto deve ter apenas uma Responsabilidade bem definida.

Um Objeto deve ser o mais Simples possível para criar e usar.

Objetos com mais de uma Responsabilidade são entidades Complexas.

"Um Objeto com apenas uma Responsabilidade é

Simples para criar, usar, modificar e reutilizar"

Dar a um Objeto mais de uma Responsabilidade é um Desperdício de tempo e recursos.

Mantenha os Objetos o mais Simples possível e será difícil quebrar essa regra.

© 2016 Delfire
www.ObjectPascalProgramming.com
Todos os direitos reservados
 Objetos
Objetos devem
devem Representar
Representar Entidades
Entidades
4
reais
reais fora
fora do
do Contexto
Contexto da
da aplicação
aplicação

Tudo que existe fora do Contexto do software é uma Entidade que existe na vida real e deve
ser representada por um Objeto dentro do programa.

"Um Objeto representa uma entidade, criatura ou

qualquer coisa fora do contexto do programa."

Não defina Entidade somente como criaturas vivas ou objetos palpáveis ao nosso redor. Um
arquivo de computador, um pixel no monitor, um carro, uma pessoa, uma molécula... tudo
que existe fora do contexto do software é uma Entidade que existe na vida real.

"O que é real? Como você define o 'real'? Se você está falando
sobre o que você pode sentir, o que você pode cheirar, o que você
pode saborear e ver, o real são simplesmente sinais elétricos
interpretados pelo seu cérebro"
— Morpheus, Matrix

© 2016 Delfire
www.ObjectPascalProgramming.com
Todos os direitos reservados
 5 Objetos
Objetos devem
devem ser
ser Imutáveis
Imutáveis

Um Objeto representa uma Entidade na vida real. Ele não é a Entidade, ele apenas à
representa dentro do contexto do programa.

Isso é o que realmente significa Encapsulamento na Orientação a Objetos.

"Um Objeto não pode ter seu estado interno alterado, pois
isso entraria em conflito com a realidade da Entidade na
qual ele representa"

Objetos Imutáveis são livres de efeitos colaterais externos. Eles são criados representando
um momento específico no tempo e devem permanecer inalterados até a sua morte.

© 2016 Delfire
www.ObjectPascalProgramming.com
Todos os direitos reservados
 6 Classes
Classes devem
que
devem possuir
que Representam
possuir Nomes
Representam oo que
Nomes
que elas
elas
são,
são, não
não oo que
que elas
elas fazem
fazem

O nome de uma Classe deve significar quem ela representa e não o que ela faz.

Não utilize nomes como Validador, Leitor, Controlador, Parser, Executor, Manager, Handle,
etc. Esses nomes dizem o que fazem, não o que são.

"O nome de uma Classe deve corresponder ou

representar uma Entidade pura ou uma versão dela"

Considere File como um nome de Entidade puro, ou seja, um Arquivo de computador ou em

papel, dependendo do contexto.

Um nome como TextFile, é uma versão específica de File.

© 2016 Delfire
www.ObjectPascalProgramming.com
Todos os direitos reservados
 Não
Não utilize
de
utilize Herança
de classes
Herança aa partir
classes Concretas
Concretas
partir
7
Só utilize Herança de Interfaces ou Classes abstratas.

Se uma Classe herdar de outra Classe concreta, é o mesmo que ter "duas cabeças num
único corpo." Você poderá instanciar Objetos destas Classes, porém cada objecto poderá
ter comportamentos totalmente diferentes, com "pensamentos" diferentes, mesmo que
ambos representem um mesmo conceito ou Entidade. Isso ocorre devido a quebra de
Encapsulamento quando sobrescrevemos seus métodos.

"Classes concretas nunca deveriam

permitir herança a partir delas, isso
seria ultrajante"

Implemente suas classes concretas como 'sealed' ou 'final' para não permitir nenhuma
quebra de Encapsulamento através da Herança.

© 2016 Delfire
www.ObjectPascalProgramming.com
Todos os direitos reservados
 8 Não
Não utilize
utilize Métodos
Métodos Estáticos
Estáticos

Objetos são representações de Entidades vivas. Como tal, eles conversam entre si.

Quando solicitamos uma tarefa a um Objeto, ele mesmo irá executar ou repassar a tarefa à
outro Objeto.

Utilizando Métodos Estáticos, qual Objeto irá executar a tarefa? Nenhum. A tarefa será
executada pelo Método Estático da Classe e nenhum Objeto estará envolvido.

"Não existe uma 'Classe superior abstrata e

estática' que um organismo vivo (Objeto) pede
para fazer algo no lugar dele"

Há pequenas exceções na utilização de Métodos Estáticos, mas todos eles são em benefício
da Performance ou algum recurso tecnológico. Métodos Estáticos simplesmente não
existem no mundo Orientado a Objetos. Evite-os.

© 2016 Delfire
www.ObjectPascalProgramming.com
Todos os direitos reservados
 Não
Não utilize
utilize 'nil'
'nil' ou
ou 'NULL'
'NULL'
9
O conceito NULL, também conhecido como "O erro de 1 bilhão de dólares", foi inventado
por Charles Antony Richard Hoare em 1965.

Em uma conferência em 2009, ele pediu desculpas por inventar a referência nula.

NULL ou nil não pertencem ao mundo Orientado a Objetos.

Não permita variáveis nulas, retorno de métodos nulos ou argumentos nulos.

"NULL, o erro de 1 bilhão de dólares"

Objetos interagem entre si. Não faz sentido, no mundo real, um Objeto tentar interagir com
'nada'.

© 2016 Delfire
www.ObjectPascalProgramming.com
Todos os direitos reservados
 10
Não
Não utilize
utilize 'Casting'
'Casting'

Não pergunte a um Objeto o tipo de Classe dele. Isso é 'rude'.

Seus Objetos devem trabalhar sob contratos, ou seja, Interfaces. Somente Objetos
qualificados — que implementam a Interface — poderão ser utilizados para fazer o serviço.

Não aceite 'penetras' em seu código.

"Se você está perguntando aos seus

'convidados' quem eles são, você já
perdeu o controle da sua festa"

Utilize Interfaces para definir na entrada quem realmente pode fazer o trabalho.

© 2016 Delfire
www.ObjectPascalProgramming.com
Todos os direitos reservados
 Sobre
Sobre oo Autor
Autor

Marcos Douglas é Pós graduado em Engenharia de Software.

Especialista em Análise e Implementação de Projetos utilizando Orientação a Objetos a

mais de 15 anos.

Consultor e CTO da Delfire, desde 2005.

Criador e idealizador do Blog www.ObjectPascalProgramming.com com a missão de

disseminar conhecimento sobre Orientação a Objetos utilizando Object Pascal.

© 2016 Delfire
www.ObjectPascalProgramming.com
Todos os direitos reservados