Вы находитесь на странице: 1из 12

10

Regras
da
da
Programao
Programao
Orientada aa Objetos
Orientada Objetos
por
Marcos Douglas B. dos Santos

Verso1.1

2016Delfire
www.ObjectPascalProgramming.com
Todososdireitosreservados
1 Programe
Programe para
no
no para
para uma
para uma
uma Interface,
Interface,
uma Implementao
Implementao

Essa talvez seja a Regra mais difundida, porm 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 variveis, atributos e argumentos dos mtodos"

Suas Classes no deveriam estar conectadas entre si diretamente, somente atravs de


Interfaces.

Toda Classe existente em sua aplicao dever implementar uma Interface que representa
uma entidade, criatura ou qualquer coisa fora do contexto do programa.

Composio, Agregao e qualquer interao entre Objetos, devero ser definidas somente
entre Interfaces.

2016Delfire
www.ObjectPascalProgramming.com
Todososdireitosreservados
Favorea
Favorea aa Composio
Composio de
de Objetos
Objetos
2
ao
ao invs
invs da
da Herana
Herana de
de Classes
Classes

Composio, no sentido de Interao entre Objetos, a Chave para a Programao


Orientada a Objetos.

Herana o mal, na maioria das vezes.

extremamente difcil construir uma rvore de herana de Classes sem quebrar o


encapsulamento, redefinir ou ocultar comportamentos de classes superiores.

"Definiram Herana como um dos pilares da


Orientao a Objetos... uma pena, pois a Composio
entre Objetos um conceito muito mais importante"

Nunca defina suas Classes baseadas em Herana apenas para reutilizar cdigo de Classes
superiores.

Herana define um Conceito abstrato sobre o que uma Classe , no o que ela faz.

Composio de Classes define Comportamento.

2016Delfire
www.ObjectPascalProgramming.com
Todososdireitosreservados
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 possvel para criar e usar.

Objetos com mais de uma Responsabilidade so entidades Complexas.

"Um Objeto com apenas uma Responsabilidade


Simples para criar, usar, modificar e reutilizar"

Dar a um Objeto mais de uma Responsabilidade um Desperdcio de tempo e recursos.

Mantenha os Objetos o mais Simples possvel e ser difcil quebrar essa regra.

2016Delfire
www.ObjectPascalProgramming.com
Todososdireitosreservados
Objetos
Objetos devem
devem Representar
Representar Entidades
Entidades
4
reais
reais fora
fora do
do Contexto
Contexto da
da aplicao
aplicao

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."

No defina Entidade somente como criaturas vivas ou objetos palpveis ao nosso redor. Um
arquivo de computador, um pixel no monitor, um carro, uma pessoa, uma molcula... 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 so simplesmente sinais eltricos
interpretados pelo seu crebro"
Morpheus, Matrix

2016Delfire
www.ObjectPascalProgramming.com
Todososdireitosreservados
5 Objetos
Objetos devem
devem ser
ser Imutveis
Imutveis

Um Objeto representa uma Entidade na vida real. Ele no a Entidade, ele apenas
representa dentro do contexto do programa.

Isso o que realmente significa Encapsulamento na Orientao a Objetos.

"Um Objeto no pode ter seu estado interno alterado, pois


isso entraria em conflito com a realidade da Entidade na
qual ele representa"

Objetos Imutveis so livres de efeitos colaterais externos. Eles so criados representando


um momento especfico no tempo e devem permanecer inalterados at a sua morte.

2016Delfire
www.ObjectPascalProgramming.com
Todososdireitosreservados
6 Classes
Classes devem
que
devem possuir
que Representam
possuir Nomes
Representam oo que
Nomes
que elas
elas
so,
so, no
no oo que
que elas
elas fazem
fazem

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

No utilize nomes como Validador, Leitor, Controlador, Parser, Executor, Manager, Handle,
etc. Esses nomes dizem o que fazem, no o que so.

"O nome de uma Classe deve corresponder ou


representar uma Entidade pura ou uma verso 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 verso especfica de File.

2016Delfire
www.ObjectPascalProgramming.com
Todososdireitosreservados
No
No utilize
de
utilize Herana
de classes
Herana aa partir
classes Concretas
Concretas
partir
7
S utilize Herana de Interfaces ou Classes abstratas.

Se uma Classe herdar de outra Classe concreta, o mesmo que ter "duas cabeas num
nico corpo." Voc poder instanciar Objetos destas Classes, porm 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 mtodos.

"Classes concretas nunca deveriam


permitir herana a partir delas, isso
seria ultrajante"

Implemente suas classes concretas como 'sealed' ou 'final' para no permitir nenhuma
quebra de Encapsulamento atravs da Herana.

2016Delfire
www.ObjectPascalProgramming.com
Todososdireitosreservados
8 No
No utilize
utilize Mtodos
Mtodos Estticos
Estticos

Objetos so representaes 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 Mtodos Estticos, qual Objeto ir executar a tarefa? Nenhum. A tarefa ser
executada pelo Mtodo Esttico da Classe e nenhum Objeto estar envolvido.

"No existe uma 'Classe superior abstrata e


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

H pequenas excees na utilizao de Mtodos Estticos, mas todos eles so em benefcio


da Performance ou algum recurso tecnolgico. Mtodos Estticos simplesmente no
existem no mundo Orientado a Objetos. Evite-os.

2016Delfire
www.ObjectPascalProgramming.com
Todososdireitosreservados
No
No utilize
utilize 'nil'
'nil' ou
ou 'NULL'
'NULL'
9
O conceito NULL, tambm conhecido como "O erro de 1 bilho de dlares", foi inventado
por Charles Antony Richard Hoare em 1965.

Em uma conferncia em 2009, ele pediu desculpas por inventar a referncia nula.

NULL ou nil no pertencem ao mundo Orientado a Objetos.

No permita variveis nulas, retorno de mtodos nulos ou argumentos nulos.

"NULL, o erro de 1 bilho de dlares"

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

2016Delfire
www.ObjectPascalProgramming.com
Todososdireitosreservados
10
No
No utilize
utilize 'Casting'
'Casting'

No 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 podero ser utilizados para fazer o servio.

No aceite 'penetras' em seu cdigo.

"Se voc est perguntando aos seus


'convidados' quem eles so, voc j
perdeu o controle da sua festa"

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

2016Delfire
www.ObjectPascalProgramming.com
Todososdireitosreservados
Sobre
Sobre oo Autor
Autor

Marcos Douglas Ps graduado em Engenharia de Software.

Especialista em Anlise e Implementao de Projetos utilizando Orientao a Objetos a


mais de 15 anos.

Consultor e CTO da Delfire, desde 2005.

Criador e idealizador do Blog www.ObjectPascalProgramming.com com a misso de


disseminar conhecimento sobre Orientao a Objetos utilizando Object Pascal.

2016Delfire
www.ObjectPascalProgramming.com
Todososdireitosreservados