Como seria definida a nossa classe "objetos de sentar" em C++?

Para começar vamos dar a ela um nome adequado, para evitar qualquer confusão de nomenclatura com a palavra objeto. Nós iremos chamá-la de Sentável, já que se pode sentar em qualquer objeto pertencente a essa classe.

Sua definição, armazenada num arquivo chamado sentavel.h, seria a seguinte:


A declaração de uma classe começa com a palavra reservada class, seguida do nome da classe, nesse caso Sentável. Notem que não usei o acento agudo na definição da classe. O compilador iria reclamar do caracter estranho, que só seria aceitável dentro de uma string (cadeia de caracteres entre aspas).

Os itens definidos com () no final são chamados de métodos. São implementados, como veremos na próxima seção, como blocos de comandos. Algo muito parecido com as procedures e functions que vimos no artigo anterior.

Assim, Sentavel, ~Sentavel, sentar, levantar, set_assentos, get_assentos, set_suportes e get_suportes são métodos.

Os itens definidos como variáveis são as propriedades (ou campos, como muitos os chamam) da classe. São valores que definem as características da classe.

Assim, qntAssentos e qntSuportes são propriedades.

Note que eu usei as palavras public, private e protected na definição da classe. Peço um pouco de sua paciência, pois só vamos discutí-las mais adiante quando falarmos de herança.

Como estamos exemplificando em C++, segui o padrão ao colocar essa definição em um arquivo de cabeçalho (header, com a extensão .h). Quando falamos na implementação da classe Sentável nós discutiremos essa técnica, que é uma herança da linguagem C.

Assim, a definição de uma classe não traz em si muita coisa. E é para ser assim mesmo. Ela é só uma definição de como a classe é, ou seja, de suas propriedades e métodos. A codificação vem depois.

Há quem ache isso "burocrático". Em geral os programadores gostam logo de sentar e codificar. Mas o fato de ter de definir as classes antes de codificá-las força o desenvolvimento de um bom hábito: o de planejar antes de codificar. Não vou discutir isso aqui, pois o tema já foi tratado no primeiro artigo dessa série.

OBSERVAÇÃO:

Junto com POO estou tentando mostrar também algumas boas práticas de programação, como a de documentar e comentar o código. Já vi bons programadores encrencados por causa da ausência de comentários. Os preguiçosos dizem que dá trabalho fazer isso, mas eu sei (por experiência própria) que dá muito mais trabalho tentar lembrar como foi que se raciocinou naquele programa depois de três anos, na hora de dar manutenção. No decorrer dessa série teremos um artigo sobre DOCUMENTAÇÃO DE SISTEMAS, que vai abranger um pouco de UML, uma ferramenta livre de modelagem UML (umbrello) e uma ferramenta livre de documentação (doxygen).