A Grande Virada: O que É um Objeto

Chegamos ao momento que, para muitos, é o mais desafiador e ao mesmo tempo o mais transformador de toda a aprendizagem de programação: a passagem para os objetos. Até aqui, seus programas manipularam valores isolados — um número, um texto, uma lista de números. Mas o mundo real não é feito de valores soltos; é feito de coisas, e cada coisa tem várias características ao mesmo tempo e comportamentos próprios. Uma pessoa tem nome, idade e altura, e pode andar e falar. Um produto tem descrição, preço e estoque, e pode ser vendido. Como representar, num programa, uma "coisa" que agrupa múltiplas características e ações numa unidade coesa? A resposta é o objeto, e compreendê-lo muda fundamentalmente como você pensa sobre programação. Esta aula não traz muito código — traz uma ideia, e peço que você a leia com a mesma atenção que dedicou à primeira aula do curso, pois é uma virada de igual importância.

O problema: valores soltos não modelam coisas

Comecemos sentindo o problema que os objetos resolvem. Suponha que você queira representar uma pessoa num programa, com seu nome, sua idade e sua cidade. Com o que sabe até agora, você usaria três variáveis separadas:

string nome = "Ana";
int idade = 30;
string cidade = "Recife";

Isso funciona para uma pessoa. Mas repare no que está implícito e frágil: essas três variáveis são soltas — nada no programa diz que elas pertencem à mesma pessoa. Elas estão relacionadas apenas na sua mente, não na estrutura do código. Agora imagine representar três pessoas: você teria nome1, idade1, cidade1, nome2, idade2, cidade2... — um emaranhado. E como passar "uma pessoa" para um método? Você teria de passar as três variáveis separadamente, torcendo para não trocar a ordem. E se uma pessoa ganhasse uma quarta característica, teria de caçar todos os lugares que lidam com pessoas. O problema é claro: valores soltos não capturam a ideia de que certas informações formam, juntas, uma coisa única. Falta uma forma de dizer "estas características pertencem a esta pessoa, como uma unidade".

A ideia central: agrupar dados numa unidade

O objeto resolve exatamente isso. Um objeto é uma unidade que agrupa, num só lugar e sob uma só identidade, múltiplas características relacionadas (e, como veremos adiante, também comportamentos). Em vez de três variáveis soltas para uma pessoa, teremos um objeto "pessoa" que contém, dentro de si, seu nome, sua idade e sua cidade. Esse objeto é uma coisa só — uma pessoa — que você pode guardar numa variável, passar a um método, colocar numa lista, tudo como uma unidade coesa. As características deixam de flutuar soltas e passam a pertencer ao objeto que as reúne.

A mudança de mentalidade é profunda e vale nomeá-la. Até agora, você pensava em programação como manipulação de valores: some estes números, compare estes textos, percorra esta lista. A partir de agora, você passa a pensar também em termos de coisas: crie uma pessoa, dê a ela um nome, pergunte sua idade, coloque várias pessoas numa lista, faça uma pessoa se apresentar. O programa deixa de ser apenas uma calculadora de valores e passa a ser um modelo de um pequeno mundo de coisas que interagem. Esse estilo de programar — organizando o programa em torno de objetos que representam coisas — chama-se programação orientada a objetos, e é o paradigma dominante no C# e em boa parte da programação moderna. As próximas aulas ensinarão sua mecânica; esta assenta a ideia.

A analogia do formulário: molde e preenchimento

Uma analogia ajuda a entender a distinção mais importante que virá nas próximas aulas — a distinção entre o molde de um tipo de coisa e as coisas concretas feitas a partir dele. Pense num formulário de cadastro em branco, impresso: ele tem campos rotulados — "Nome: ____", "Idade: ____", "Cidade: ____" — mas não contém dados de ninguém. Esse formulário em branco é um molde: ele define quais características uma pessoa cadastrada terá, sem ser, ele próprio, nenhuma pessoa específica.

Agora, quando você preenche uma cópia desse formulário com "Ana, 30, Recife", cria um cadastro concreto — uma pessoa específica. Você pode preencher outra cópia com "Beto, 25, Olinda", criando outra pessoa. O formulário em branco (o molde) é um só; os formulários preenchidos (as pessoas concretas) podem ser muitos, cada um com seus próprios dados, mas todos com a mesma estrutura de campos, porque vieram do mesmo molde.

Essa é exatamente a relação entre uma classe e um objeto, os dois conceitos que estruturam a programação orientada a objetos. A classe é o molde — o formulário em branco — que define quais características (e comportamentos) um tipo de coisa terá. O objeto é uma coisa concreta feita a partir desse molde — um formulário preenchido — com seus próprios valores. Uma classe Pessoa define que toda pessoa tem nome, idade e cidade; a partir dela, criamos objetos-pessoa concretos: a Ana, o Beto, cada um com seus dados. Uma classe, muitos objetos. Guarde essa dupla — classe é o molde, objeto é a coisa feita a partir dele —, pois ela é a chave de tudo o que vem a seguir.

Você já usou objetos sem saber

Talvez o conceito lhe pareça abstrato, então observe que você já vem usando objetos desde as fases anteriores, sem que os chamássemos assim. Quando você escreveu nome.Length (Aula #09) para descobrir o tamanho de um texto, nome era um objeto — uma coisa do tipo string — e Length era uma de suas características. Quando escreveu tarefas.Add("Estudar") (Aula #20), tarefas era um objeto do tipo List, e Add era um de seus comportamentos. O ponto (.) que usamos para acessar Length, Add, ToUpper era, o tempo todo, o operador de "acessar algo de dentro de um objeto". Aquelas capacidades — o Length de uma string, o Add de uma lista — eram características e comportamentos de objetos que outras pessoas criaram e nos entregaram prontos. A novidade das próximas aulas é que você aprenderá a criar seus próprios tipos de objeto, definindo suas próprias características e comportamentos. Você deixa de ser apenas usuário de objetos alheios e passa a ser criador dos seus.

Por que isso vale o esforço

Serei honesto: a orientação a objetos exige um esforço mental real de quem a encontra pela primeira vez, e é normal que leve algumas aulas para "clicar". Vale a pena, e explico por quê. Ao permitir que você modele o programa em termos das coisas do problema que está resolvendo — pessoas, produtos, pedidos, contas —, a orientação a objetos torna programas grandes muito mais fáceis de entender e modificar, porque a estrutura do código passa a espelhar a estrutura do mundo que ele representa. Um programa de uma loja que tem objetos Produto, Cliente e Pedido é imediatamente mais compreensível do que um emaranhado de variáveis soltas fazendo o mesmo trabalho. Além disso, agrupar dados e comportamentos em objetos permite reutilizá-los, protegê-los de uso indevido, e organizá-los de formas que aprenderemos a apreciar. A orientação a objetos é, no fundo, uma ferramenta de organização do pensamento — e é por isso que domina a programação profissional. Invista nas próximas aulas; a recompensa é grande.

Esta foi uma virada de perspectiva, não um acréscimo de sintaxe. Até aqui os programas manipulavam valores isolados; agora existe a noção de que uma coisa do mundo real tem várias características e comportamentos ao mesmo tempo, e de que faz sentido representá-la como uma unidade coesa em vez de um punhado de variáveis soltas que o programador precisa lembrar de manter juntas.

E ficou evidente que você já vinha usando objetos sem saber: a string, com seu Length e seus métodos próprios, e a List, com sua contagem e suas operações, sempre foram exatamente isso — dados e comportamento reunidos sob um mesmo nome. O conceito não é estranho, era apenas invisível.

Fontes e leituras recomendadas

• Programação orientada a objetos (C#) — uma introdução oficial ao paradigma dos objetos; a base conceitual desta fase.
• Objetos e classes (visão geral) — a distinção entre classe (molde) e objeto (instância), central nesta aula.
• Conceitos de orientação a objetos — o panorama dos pilares da programação orientada a objetos, que exploraremos nas próximas aulas.
• O que é uma classe — a definição de classe como molde de objetos, para revisitar.
• História da orientação a objetos — um panorama de como esse paradigma surgiu e se tornou dominante, para contexto.

Exercícios

Exercício 1

Com suas palavras, explique o problema dos "valores soltos" apresentado na aula. Por que representar uma pessoa com três variáveis separadas (nome, idade, cidade) é frágil, especialmente quando há muitas pessoas a representar?

Exercício 2

Explique a analogia do formulário em branco e do formulário preenchido. Na analogia, o que corresponde a uma classe e o que corresponde a um objeto? Por que pode haver muitos objetos e apenas uma classe?

Exercício 3

A aula afirma que você "já usou objetos sem saber". Dê dois exemplos, das fases anteriores, de objetos que você utilizou, identificando em cada um uma característica ou um comportamento que você acessou (com o ponto).

Exercício 4

Pense em três "coisas" do seu cotidiano (por exemplo, um carro, um livro, uma conta bancária) e, para cada uma, liste três características que ela teria se fosse modelada como um objeto num programa. Não escreva código; apenas descreva as características, como faria nos campos de um formulário.

Exercício 5

Sem código: explique, com suas palavras, a diferença de mentalidade entre "pensar em valores" e "pensar em objetos". Por que a aula descreve a orientação a objetos como uma ferramenta de "organização do pensamento", e não apenas uma técnica de programação?