Este post é continuação da
[Parte 01 de 02]. Recomenda-se a prévia leitura daquele post antes de se aprofundar neste post.
Objetos e Estrutura de Dados
Esconder implementação
não é apenas uma questão de adicionar uma camada de funções entre as
variáveis. Esconder implementação é uma questão de abstração. Uma
classe
não deve expor suas variáveis por meio de métodos de acesso e
mutação
(getters e
setters). Em vez disso, deve expor
interfaces abstratas que permitem aos seus usuários a manipulação dos
seus dados, sem que os usuários sejam obrigados a conhecer sua implementação.
Considere os seguintes exemplos:
public interface Vehicle {
double getFuelTankCapacityInGallons();
double getGallonsOfGasoline();
}
public interface Vehicle {
double getPercentFuelRemaining();
}
O primeiro exemplo se comunica usando termos concretos, enquanto o
segundo se comunica por meio da
abstração da percentagem de combustível.
A segunda forma é preferível, pois o ideal é não expor os detalhes dos
dados.
É melhor expressar a informação em termos abstratos. Isso
não é alcançado pelo mero uso de interfaces acompanhadas de
getters/setters.
É preciso dispensar muita atenção quanto à melhor forma de representar a
informação que um objeto contém. A pior escolha é simplesmente ficar
adicionando
getters e
setters sem um critério cuidadosamente escolhido.
Assimetria entre Dados e Objeto
Objetos escondem seus
dados por trás de abstrações e expõem funções que operam sobre os dados.
Estrutura de dados (
data structure) expõem sua informação e não possuem
funções substanciais ou relevantes. O tipo clássico de estrutura de dados é uma
classe com variáveis públicas e nenhuma função. Vê-se, portanto, que
'objetos' e 'estrutura de dados' são conceitos bastante opostos.
Programação
procedimental (código que usa estrutura de dados) torna fácil a adição
de novas funções sem que seja preciso alterar a estrutura dos dados. Mas
a adição de novas estruturas de dados é difícil porque todas as funções
existentes necessariamente precisarão sofrer alterações.
Já
a programação orientada por objetos torna fácil a adição de novas
classes sem a necessidade de alteração das funções existentes. Mas torna
difícil a adição de novas funções porque muitas classes precisarão
ser alteradas. Assim, tarefas difíceis para a
programação orientada por objetos são fáceis na procedimental, e tarefas
difíceis na procedimental são fáceis na orientada por objetos.
Em
qualquer sistema complexo haverá momentos em que orientação por objetos
será mais apropriada e momentos em que programação procedimental será a melhor
opção. Por isso, é um mito afirmar que "tudo é um objeto". Muitas vezes você realmente quer apenas estrutura de dados simples
com linguagem procedimental operanto sobre elas. Nem sempre haverá a necessidade de adicionar uma camada orientada por objetos.
A Lei de Demeter
Objetos escondem seus dados e expõem
operações. Logo, objetos não devem expor sua
estrutura interna por meio
de métodos de acesso (
getters). A noção fundamental da Lei de Demeter é que um objeto deve saber o mínimo possível a respeito da estrutura
ou propriedade de qualquer outra coisa (outras classes e inclusive subcomponentes).
Esses são os princípios da Lei de Demeter:
- Cada
unidade deve ter conhecimento limitado sobre as outras unidades:
somente sobre unidades intimamente relacionadas com a unidade atual.
- Cada unidade deve conversar somente com os "amigos"; não converse com estranhos.
- Somente converse com seus amigos imediatos.
A criação de
estrutura híbridas,
ou seja, que são metade objeto e metade estrutura de dados, são um
convite para a violação da lei de Demeter. Esses tipos híbridos possuem
funções que fazem coisas significativas e também variáveis públicas ou
então
métodos públicos que acessam e modificam
variáveis privadas (que, por isso mesmo, terminam sendo acessadas como se fossem públicas). Esse tipo híbrido termina facilitando o uso de suas variáveis por
funções externas da mesma forma que a programação procedimental usaria uma estrutura de dados, violando claramente a lei de Demeter.
Tais tipos híbridos devem ser evitados.
Registro Ativo (Active Record)
Registros Ativos são
uma forma especial de Objetos para Transferência de Dados (
Data Transfer
Objects). São estruturas de dados com
variáveis públicas ou
métodos
públicos de acesso às variáveis privadas. Em geral, são traduções de tabelas de
banco de dados ou de outros tipos de fontes de dados.
É
muito comum desenvolvedores tratarem esse tipo de estrutura de dados
como se fossem objetos inserindo métodos de regras de negócios (
business
rules) neles. Ocorre que isso é exatamente o que os transforma no tipo
híbrido acima referido. A solução é tratar o Active Record como se fosse
apenas uma estrutura de dados e criar
objetos separados que contenham
métodos e escondam seus dados internos (os dados internos provavelmente serão apenas
instâncias do
Active Record).
Manipulação de Erros
Erros são inveitáveis. Por isso, o manuseio de erros é algo importante. Porém, se a manipulação do erro
obscurecer a
lógica do programa, é porque está sendo feita de forma pobre
ou inapropriada.
A técnica de retornar "códigos de
erros" (
error codes) era necessária na época em que não havia as exceções (
exceptions).
O problema dessa abordagem é que obriga o usuário da função a lidar com
os erros de forma
imediata, torando-se tarefa de fácil esquecimento, além de
obscurecer a implementação do código-fonte.
Compare os dois exemplos abaixo.
public class DeviceController {
...
public void sendShutDown() {
DeviceHandle handle = getHandle(DEV1);
// Check the state of the device
if (handle != DeviceHandle.INVALID) {
// Save the device status to the record field
retrieveDeviceRecord(handle);
// If not suspended, shut down
if (record.getStatus() != DEVICE_SUSPENDED) {
pauseDevice(handle);
clearDeviceWorkQueue(handle);
closeDevice(handle);
} else {
logger.log("Device suspended. Unable to shut down");
}
} else {
logger.log("Invalid handle for: " + DEV1.toString());
}
}
...
}
Agora com o gerenciamento do erro por meio de exceções:
public class DeviceController {
...
public void sendShutDown() {
try {
tryToShutDown();
} catch (DeviceShutDownError e) {
logger.log(e);
}
}
private void tryToShutDown() throws DeviceShutDownError {
DeviceHandle handle = getHandle(DEV1);
DeviceRecord record = retrieveDeviceRecord(handle);
pauseDevice(handle);
clearDeviceWorkQueue(handle);
closeDevice(handle);
}
private DeviceHandle getHandle(DeviceID id) {
...
throw new DeviceShutDownError(
"Invalid handle for: " + id.toString()
);
...
}
...
}
Perceba
como no segundo caso tudo ficou muito mais claro. Os algorítimos para o
desligamento do dispositivo e a manipulação do erro ficaram
separados.
Não retorne Null
Se você cair na tentação de retornar
null, pare e pense se não seria melhor lançar uma exceção (
thrown exception) ou então retornar um objeto do tipo
Special Case.
O problema de trabalhar com funções que retornam
null
é que você tem que lembrar de lidar com esse retorno toda vez que ele
for possível, o que leva à duplicação de código e torna sua programação
propensa a erros, pois em diversos momentos você terminará esquecendo de
lidar com o
null como valor de retorno.
Se você estiver trabalhando com uma API que possui retorno
null,
o melhor é encapsular esses métodos com outros métodos que lancem
exceções ou, ainda, que retornem objetos de casos especiais (
Special Case Objects).
Não passe Null
Da mesma forma que não é bom retornar
null, não é boa ideia passar
null
como argumentos de funções. Essa prática em geral está associada com
funções que possuem diversos argumentos e eles devem ser
fornecidos na ordem em que foram declarados. Assim, para pular um ou
algum dos argumentos, passa-se o
null. A prática é ruim porque
obriga a que função seja escrita de forma a verificar e testar argumento por argumento. Não é eficiente e
propicia esquecimentos e erros. O melhor é seguir a regra de que as
funções devem ter nenhum, um, ou, quando muito, dois argumentos, de forma
que não seja necessário "pular" argumentos declarados nem ficar verificando argumentos e o tipo deles.
Classes
Classes devem ser pequenas!
Tal como afirmado em
relação às funções, as classes também devem ser pequenas. Porém, não se
deve medir o tamanho de uma classe em linhas, mas sim em
responsabilidades.
O primeiro indicativo é o nome da Classe. Se não conseguir encontrar um nome conciso
para a classe, que expresse sua responsabilidade, é porque
provavelmente a classe é grande demais. Quanto mais ambíguo o nome da classe, maior a chance de ela apresentar muitas responsabilidades. Por exemplo,
classes que levam os nomes
Processor ou
Manager ou
Super em geral apontam o indevido acúmulo de muitas responsabilidades.
O Princípio da Responsabilidade Única (Single Responsibility Principle)
O princípio da responsabilidade única estabelece que uma classe ou módulo deve ter uma, e apenas uma,
razão para mudar.
O princípio fornece tanto a definição de responsabilidade como um guia
para o tamanho da classe. Classes devem ter apenas uma responsabilidade -
uma razão para mudar.
Muitos programadores temem que
um grande números de classes pequenas tornará o sistema difícil de ser
entendido. No entanto, um sistema com diversas classes pequenas não tem
mais partes mutáveis do que um sistema com poucas porém enormes classes.
O sistema deve ser composto, portanto, de diversas classes pequenas.
Cada classe deve ter apenas uma responsabilidade encapsulada, ou seja, deve possuir
apenas uma razão para ser alterada, e deve colaborar com algumas outras
classes para que o sistema alcance a finalidade desejada.
Coesão
Classes
devem ter número pequeno de variáveis (
instance variables). Cada um dos
métodos de uma classe deve manipular uma ou algumas dessas variáveis.
Em geral, quanto mais variáveis um método manipular, mais coeso esse
método será em relação à classe. Porém, nem sempre será possível ou mesmo
aconselhável que uma classe seja criada com tal nível de coesão. Mas, de qualquer forma, é desejável que o nível de coesão seja
alto.
Atenção: a
estratégia de manter as funções pequenas e a lista de parâmetros
pequena ou até inexistente pode levar a uma proliferação de variáveis da
classe que podem terminar sendo usadas apenas por um subgrupo de métodos da classe. Quando isso
acontecer, provavelmente significa que pelo menos uma nova classe está
tentando sair da classe maior. Você deve tentar separar as variáveis e
métodos em duas ou mais classes, de modo que a
nova classe seja mais coesa.
Manter coesão resulta em diversas classes pequenas
O
mero ato de quebrar funções grandes em funções menores, por si só, já leva a uma proliferação de classes. Imagine uma função extensa com diversas
variáveis declaradas dentro da função. Digamos que você queira extrair
uma pequena parte dessa função para uma função separada. No entanto, o
código que você deseja separar usa quatro das variáveis declaradas na
função. Vem a pergunta: você deverá passar essas variáveis para a função extraída por meio
de argumentos?
Com certeza
não!
Se essas quatro
variáveis forem promovidas a variáveis da classe (
instance variables),
você poderá extrair o código sem ter que passar nenhuma variável como
argumento.
No entanto, por vezes isso pode ocasionar um
acúmulo de mais e mais variáveis da classe que existem somente para
permitir que algumas funções as compartilhem, e não que sejam necessariamente usadas
pela maioria das funções da classe. Conforme acima exposto, esse acúmulo de variáveis
não usadas pela maioria dos métodos da classe significa falta de coesão.
Mas pare e pense: se há algumas funções que precisam compartilhar determinadas
variáveis, então isso significa que tais funções e tais variáveis
já merecem mesmo uma classe somente para elas. É o princípo da coesão em ação.
Logo, se uma
classe começar a perder a coesão em razão da separação das funções em
funções mais curtas, separe a própria classe em tantas classes quanto
forem necessárias para que cada uma delas mantenha sua própria coesão.
Organizando para a Alteração
Em
todos os sistemas as mudanças podem ser contínuas. Só que toda mudança
causa o risco de o restante do código não funcionar mais. O programador então, resite em fazer alterações. Por isso, em um sistema
limpo (ou
"clean"), as classes devem ser organizadas de forma a reduzir os riscos
decorrentes de mudanças.
A classe
Sql a seguir é
usada para gerar comandos SQL apropriados a partir de metadados
que forem fornecidos. Para os fins do exemplo, ainda não se trata de classe completa. Falta-lhe, por exemplo, o suporte para comandos do
tipo
update. Quando chegar a hora de implementar tais métodos,
teremos que
abrir a classe para as mudanças. O problema é que ao abrir a
classe introduzimos o risco próprio da mudança, qual seja,
quebrar outras partes do código.
public class Sql {
public Sql(String table, Column[] columns)
public String create()
public String insert(Object[] fields)
public String selectAll()
public String findByKey(String keyColumn, String keyValue)
public String select(Column column, String pattern)
public String select(Criteria criteria)
public String preparedInsert()
private String columnList(Column[] columns)
private String valuesList(
Object[] fields, final Column[] columns
)
private String selectWithCriteria(String criteria)
private String placeholderList(Column[] columns)
}
A
classe
Sql acima deverá sofrer alterações sempre que adicionarmos um
novo tipo de comando. Deverá mudar também quando alterarmos os detalhes de
um único tipo de comando, como por exemplo se precisarmos alterar a
funcionalidade
select para suportar
subselects. Essas
duas razões para mudar indicam que a classe
Sql viola o princípio da responsabilidade única
(single responsibility principle).
Essa violação pode ser facilmente percebida até mesmo pela forma como a classe foi organizada. Existem métodos privados, como por exemplo o
selectWithCriteria, que visivelmente somente se relaciona com os comandos do tipo
select. Métodos privados que se relacionam somente com pequeno subgrupo de
funções da classe são bons indicativos da necessidade de melhoria no
design dessa classe.
Se
não houver a menor necessidade de atualizar a classe (ou "abrir a classe"
para mudança), então em princípipo ela poderia ser deixada como está. Mas
a partir do momento que você se pegar "abrindo a classe" para mudança,
deverá considerar a possibilidade de melhorar o
design dela.
Imagine a
solução a seguir ilustrada. Nela, cada uma das interfaces públicas dos
métodos definidos na classe anterior passou a integrar cada uma
sua
própria classe derivada da classe
Sql. E os métodos privados, tais como
valuesList, são movidos diretamente para onde são necessários. E o comportamento privado
comum foi isolado em um par de classes utilitárias,
Where e
ColumnList.
abstract public class Sql {
public Sql(String table, Column[] columns)
abstract public String generate();
}
public class CreateSql extends Sql {
public CreateSql(String table, Column[] columns)
@Override public String generate()
}
public class SelectSql extends Sql {
public SelectSql(String table, Column[] columns)
@Override public String generate()
}
public class InsertSql extends Sql {
public InsertSql(String table, Column[] columns, Object[] fields)
@Override public String generate()
private String valuesList(
Object[] fields, final Column[] columns
)
}
public class SelectWithCriteriaSql extends Sql {
public SelectWithCriteriaSql(
String table, Column[] columns, Criteria criteria
)
@Override public String generate()
}
public class SelectWithMatchSql extends Sql {
public SelectWithMatchSql(
String table, Column[] columns, Column column, String pattern
)
@Override public String generate()
}
public class FindByKeySql extends Sql {
public FindByKeySql(
String table, Column[] columns,
String keyColumn, String keyValue
)
@Override public String generate()
}
public class PreparedInsertSql extends Sql {
public PreparedInsertSql(String table, Column[] columns)
@Override public String generate() {
private String placeholderList(Column[] columns)
}
}
public class Where {
public Where(String criteria)
public String generate()
}
public class ColumnList {
public ColumnList(Column[] columns)
public String generate()
}
Assim, o
código em cada classe torna-se extremamente
simples. O risco de uma
função quebrar outra ficou reduzido a praticamente zero. Além disso, o
isolamento de cada classe tornou a produção de testes tarefa fácil (
Test Driven Development).
E quando chegar a hora de adicionar o comando
update, nenhuma das classes existentes precisará ser alterada. A lógica para criar comandos
update será escrita em nova subclasse da classe
Sql chamada
UpdateSql.
Nenhum outro código no sistema será quebrado por conta desse acréscimo.
Assim, a
lógica reestruturada representa o melhor dos mundos. Suporta o
princípio da responsabilidade única e também suporta outro fator chave
do desenvolvimento orientado por objetos, que é o "Princípio Aberto-fechado" (
Open-Closed Principle).
Classes devem estar abertas a extensões mas fechadas para modificações. A classe
Sql
reestruturada está aberta para permitir nova funcionalidade por meio de
subclasses, mas isso pode ser feito mantendo-se as demais classes
fechadas. Simplesmente colocaremos a nova classe
UpdateSql no lugar dela.
Em um sistema ideal, incorporamos novas funcionalidades
estendendo o sistema
e não fazendo modificações no código existente.
Isolando das Mudanças
Classes
concretas implementam detalhes (código) e classes abstratas
representam
apenas conceitos. Uma classe cliente que dependa de
detalhes concretos
está em perigo quando esses detalhes mudarem. Por isso,
interfaces e
classes
abstratas podem ser introduzidas para ajudar a ilosar o impacto desses
detalhes.
A dependência de detalhes concretos torna complicados os testes do sistema. Imagine a classe
Portfolio que dependa da API externa
TokyoStockExchange
para obter o valor do portfolio. Testar a classe vai ser extremamente
difícil por conta da mutabilidade do valor retornado. A cada cinco
minutos a resposta será diferente.
Em vez de definir a classe
Portfolio de forma que ela dependa diretamente de
TokyoStockExchange, podemos criar uma interface,
SotckExchange, que declara um único método:
public interface StockExchange {
Money currentPrice(String symbol);
}
Então definimos
TokyoStockExchange como
implementação dessa interface. Também nos certificamos de que o construtor de
Portfolio receba como argumento uma referência do tipo
StockExchange:
public Portfolio {
private StockExchange exchange;
public Portfolio(StockExchange exchange) {
this.exchange = exchange;
}
// ...
}
Agora poderá ser criada uma implementação passível de teste da interface
SotckExchange que
emula a
TokyoStockExchange. Essa implementação de teste irá ajustar o valor atual para qualquer símbolo (variável
symbol
no exemplo) que usemos no teste. Se nosso teste demonstrar a compra de
cinco ações da empresa imaginária MSFT para o nosso portfolio, criamos a
implementação do teste para sempre retornar $100 por ação dessa empresa.
Nossa implementação teste da interface
StockExchange fica
reduzida a uma simples busca de tabela. Podemos então escrever um teste
que espera o total de $500 para nosso valor do portfolio quando são
adicionadas 5 ações.
public class PortfolioTest {
private FixedStockExchangeStub exchange;
private Portfolio portfolio;
@Before
protected void setUp() throws Exception {
exchange = new FixedStockExchangeStub();
exchange.fix("MSFT", 100);
portfolio = new Portfolio(exchange);
}
@Test
public void GivenFiveMSFTTotalShouldBe500() throws Exception {
portfolio.add(5, "MSFT");
Assert.assertEquals(500, portfolio.value());
}
}
Se
um sistema for separado o suficiente para ser testado dessa forma, será
também mais flexível para promover o reuso de código. Assim, os
elementos ficam isolados um dos outros e isolados de mudanças. Essa
classe então atenderá a outro princípio de elaboração de classes
conhecido como Inversão de Dependência (
Dependency Inversion Principle - DIP). Em resumo, esse princípio estabelece que
as classes devem depender de abstrações e não de detalhes concretos.
Em vez de depender da implementação de detalhes da classe
TokyoStockExchange, nossa classe
Portfolio agora depende da interface
StockExchange.
Essa interface representa o conceito abstrato de perguntar qual é o
preço corrente de um símbolo ('symbol' no exemplo). Essa abstração isola
todos os detalhes específicos para se obter tal preço, incluindo de onde e
de que forma esse preço pode ser obtido.
Há muito mais
Nem de longe o resumo contido nesses posts esgota o tema das boas práticas em programação.
Em posts futuros procurarei resumir mais conceitos e práticas interessantes.
De qualquer forma, há muito material disponível para pesquisa e sem dúvida o programador profissional deve se aprimorar constantemente para escrever o desejado "clean code".
