3.1.1 Caixas pretas
Ao levantar o capô de um carro, você encontrará uma coleção enorme de componentes mecânicos. Você provavelmente reconhecerá o motor e o recipiente de água do limpador de pára-brisa. Um mecânico será capaz de identifi car vários outros componentes, como a transmissão e o módulo de controle eletrônico – o dispositivo que controla a sincroniza- ção das velas de ignição e o fl uxo de gasolina no motor. Mas pergunte ao seu mecânico o que está dentro do módulo de controle eletrônico e provavelmente ele não saberá o que responder.
É uma caixa preta, algo que funciona de uma maneira mágica. Um mecânico nunca abriria a caixa – ela contém componentes eletrônicos que só podem ser revisados na fábrica. Naturalmente, o dispositivo pode ter uma outra cor além do preto e talvez nem mesmo tenha uma forma de caixa. Mas os engenheiros utilizam o termo “caixa pre- ta” para descrever qualquer dispositivo cujo funcionamento interno permanece oculto. Observe que uma caixa preta não é totalmente misteriosa. Sua interação com o mundo externo é bem-defi nida. Por exemplo, o mecânico pode testar se o módulo de controle do motor envia a descarga eletrônica correta para as velas de ignição.
Por que os fabricantes colocam caixas pretas nos carros? A caixa preta simplifi ca signifi cativamente o funcionamento da mecânica do carro, o que resulta em custos de manutenção mais baixos. Se a caixa falhar, é simplesmente substituída por uma nova. Antes dos módulos de controle do motor terem sido inventados, o fl uxo de gasolina no motor era regulado por um dispositivo mecânico chamado carburador, um grande caos de molas e engates caros de ajustar e consertar.
3.1 Níveis de abstração 100 3.2 Especifi cando a interface pública
de uma classe 103
SINTAXE 3.1: Defi nição de método 105
SINTAXE 3.2: Defi nição de construtor 106
SINTAXE 3.3: Defi nição de classe 107 3.3 Comentando a interface
pública 107
DICADEPRODUTIVIDADE 3.1: O utilitário javadoc
3.4 Campos de instância 110
SINTAXE 3.4: Declaração de campo de instância 112
3.5 Implementando construtores e métodos 112
SINTAXE 3.5: A instrução return 114
COMOFAZER 3.1: Implementando uma classe 115
3.6T Teste de unidade 119
DICADEPRODUTIVIDADE 3.2: Utilizando a linha de comando de maneira efi ciente
3.7 Categorias de variáveis 121
ERROCOMUM 3.1: Esquecendo de inicializar referências a objetos em um construtor 123 3.8 Parâmetros de método implícitos e
explícitos 124
ERROCOMUM 3.2: Tentando chamar um método sem um parâmetro implícito 125
TÓPICOAVANÇADO 3.1: Chamando um construtor a partir de um outro
FATOALEATÓRIO 3.1: Urnas eletrônicas 3.9G Classes de formas gráfi cas 126
COMOFAZER 3.2: Desenhando formas gráfi cas 131
FATOALEATÓRIO 3.2: Computação gráfi ca
Naturalmente, para muitos motoristas, o carro inteiro é uma “caixa preta”. A maioria deles não conhece nada sobre o funcionamento interno e nunca vai querer abrir o capô. O carro tem pedais, botões e uma tampa de tanque de gasolina. Se você fornecer as entradas corretas, ele fará o que deve ser feito, transportá-lo de um lugar a outro.
E para o fabricante do módulo de controle do motor, os transistores e capacitores inter- nos são caixas pretas, magicamente produzidas pelo fabricante do componente eletrônico. Em termos técnicos, uma caixa preta fornece o encapsulamento, escondendo os deta- lhes sem importância. O encapsulamento é muito importante na resolução de problemas por humanos. Um mecânico é mais efi ciente quando a única decisão é testar o módulo de controle eletrônico e substituí-lo quando ele falha, sem que precise pensar nos sensores e transistores internos. Um motorista é mais efi ciente quando a única preocupação é encher o tanque, não pensar no motor ou no módulo de controle eletrônico interno.
Mas há um outro aspecto do encapsulamento. Alguém tem de propor o conceito correto para cada caixa preta. Por que os fabricantes de peças automotivas constroem módulos de controle eletrônico e não um outro dispositivo? Por que os fabricantes de carros constroem carros e não helicópteros pessoais?
Os conceitos são descobertos por meio do processo de abstração, excluindo os re- cursos não-essenciais até que apenas a essência do conceito permaneça. Por exemplo, “carro” é uma abstração, descrevendo dispositivos que transportam pequenos grupos de pessoas que viajam por via terrestre e consomem gasolina. Essa é a abstração correta? Ou um veículo com um motor elétrico seria um “carro”? Não responderemos a essa per- gunta e, em vez disso, analisaremos a importância do encapsulamento e da abstração na ciência da computação.
3.1.2 Projeto orientado a objetos
Antigamente, programas de computador manipulavam tipos primitivos como números e caracteres. À medida que esses programas tornaram-se mais complexos, passaram a manipular um número cada vez maior desses tipos primitivos até o ponto em que os programadores não conseguiam mais acompanhar esse processo. Era demasiadamente confuso memorizar todos esses detalhes. Como resultado, programadores davam instru- ções erradas aos computadores e estes as executavam rigorosamente conforme instruí- dos, produzindo respostas também erradas.
Naturalmente, a resposta a esse problema era óbvia. Os desenvolvedores de soft- ware aprenderam rapidamente a gerenciar a complexidade. Eles encapsularam cálculos rotineiros, criando “caixas pretas” de software que poderiam ser colocadas em fun- cionamento sem a preocupação com as partes internas. Eles utilizavam o processo de abstração para criar tipos de dados que estão em um nível mais alto do que números e caracteres.
No momento em que este livro estava sendo escrito, a abordagem mais comum para estruturar a programação de computadores era a abordagem orientada a objetos. As cai- xas pretas a partir das quais um programa é produzido são chamadas objetos. Um objeto tem uma estrutura interna – talvez apenas alguns números, talvez outros objetos – e um comportamento bem-defi nido. Naturalmente, a estrutura interna permanece escondida do programador que a usa. Esse programador só aprende o comportamento do objeto e então o coloca em funcionamento para alcançar um objetivo de nível mais alto.
Quem projeta esses objetos? Outros programadores! O que eles contêm? Outros objetos! É aqui que as coisas começam a fi car confusas para estudantes iniciantes. Na vida real, os usuários das caixas pretas são bem diferentes dos projetistas e é fácil entender os níveis de abstração (veja Figura 1). Com programas de computador, tam- bém há níveis de abstração (veja Figura 2), mas eles não são tão intuitivos aos não- iniciados. Para tornar as coisas ainda mais confusas, freqüentemente você precisará trocar de papel, sendo o projetista de objetos pela manhã e o usuário desses mesmos objetos à tarde. Nesse sentido, você será como os primeiros fabricantes de automó- veis, que produziam, sem ajuda, volantes e eixos e então incorporavam suas criações a um carro.
Há outro aspecto desafi ador no projeto de objetos. O software é infi nitamente mais fl exível do que o hardware porque o software está livre das limitações físicas. Projetistas de componentes eletrônicos podem explorar um número limitado de efeitos físicos para criar transistores, capacitores e assim por diante. Fabricantes de automóveis não conse- guem produzir facilmente helicópteros pessoais devido a uma infi nidade de limitações físicas, por exemplo, consumo de combustível e segurança. Mas, em software, qualquer coisa é possível. Com poucas restrições externas, você pode projetar abstrações boas e ruins com igual facilidade. Entender o que constitui um bom projeto é uma parte impor- tante da educação do engenheiro de software.
3.1.3 Engatinhar, caminhar, correr
No Capítulo 2, você aprendeu a ser um usuário de objetos. Você viu como obter objetos, como manipulá-los e como usá-los em um programa. Naquele capítulo, seu papel era análogo ao do engenheiro automotivo que aprende a utilizar um módulo de controle de motor e a tirar proveito desse comportamento para construir um carro.
Object Object Usuário de computador Programador de aplicativos Programador de aplicativos Programa de computador Programador de sistemas Usa Usa Usa Projeta Projeta Projeta
Figura 2 Níveis de abstração no projeto de software. Capacitores e transistores Unidades de controle eletrônico Motorista Engenheiro automotivo Usa Usa Usa Projeta Projeta Projetista de peças automotivas Carro
Figura 1 Níveis de abstração no projeto automotivo.
Neste capítulo, você passará para a implementação de classes. Forneceremos um projeto que descreve o comportamento dos objetos de uma classe. Você aprenderá as técnicas de programação necessárias em Java que permitem que seus objetos realizem o comportamento desejado. Nestas seções, seu papel será análogo ao do fabricante de peças automotivas que monta um módulo de controle do motor a partir dos transistores, capacitores e outros componentes eletrônicos.
Nos Capítulos 8 e 12, você aprenderá mais sobre como projetar suas próprias classes. Aprenderá também as regras de um bom projeto e como descobrir o comportamento apro- priado dos objetos. Nesses capítulos, seu trabalho será análogo ao do engenheiro de peças automotivas que especifi ca como um módulo de controle do motor deve funcionar.
AUTOVERIFICAÇÃODAAPRENDIZAGEM
1. Nos Capítulos 1 e 2, você utilizou System.out como uma caixa preta para fazer a saída aparecer na tela. Quem projetou e implementou System.out?
2. Suponha que você esteja trabalhando em uma empresa que produz um software de fi nanças pessoais. Você foi encarregado de projetar e implementar uma classe para representar contas bancárias. Quem serão os usuários dessa classe?