Uma classe define um tipo de dado, de modo muito semelhante a struct em C. Em ciência da computação, um tipo consiste de um conjunto de estados possíveis e um conjunto de operações que realizam a transição entre os estados do tipo. Assim, int é um tipo porque tem tanto um conjunto de estados, quanto operações como i + j ou i++. Exatamente da mesma maneira, uma class consiste de um conjunto de operações (normalmente public:), e um conjunto de (normalmente não-public:) bits de dados representando os valores abstratos que as instâncias do tipo podem ter.

Pense em int como uma class que tem uma função membro chamada operator++, etc.

Nota: Um programador C pode pensar em uma class como uma C struct, cujos membros são, por default, private. Mas se isso é tudo o que pensa de uma class, então, provavelmente, você precisa fazer um esforço para mudar o seu paradigma.

Após a declaração int i; podemos dizer que "i é um objeto do tipo int." Em OO/C++, "objeto" normalmente significa "uma instância de uma classe". Assim, uma classe define o comportamento dos objetos (instâncias) possíveis.

• Visão simplificada significa que detalhes desnecessários ao usuários são intencionalmente ocultos. Isso reduz a margem de erros do usuário.
• Vocabulário do usuário significa que o usuário pode utilizar a interface, sem que para isso tenha que aprender um novo conjunto de termos ou conceitos. Isso reduz a curva de aprendizado do usuário para utilização da classe.

O critério chave aqui é separar as partes voláteis das partes estáveis da classe. Encapsulamento põe uma barreira em torno das partes voláteis, impedindo que outros módulos do software acessem as partes voláteis da classe, outros módulos podem acessar apenas as partes estáveis da classe. Isso evita que outros módulos sejam afetados quando as partes voláteis da classe sofrerem alterações. No contexto de OO um módulo de software é normalmente uma classe ou um grupo compacto de classes.

As partes voláteis são a implementação dos detalhes. Se o módulo é uma classe única, as partes voláteis são normalmente encapsuladas usando as palavras chave private: ou protected. Se o módulo é um grupo compacto de classes, o encapsulamento pode ser usado para negar acesso a classes inteiras do grupo. Herança pode também ser usada como uma forma de encapsulamento.

As partes estáveis são as interfaces. Uma boa interface fornece uma visão simplificada, usa o vocabulário do usuário e é projetada de fora para dentro. (Aqui usuário significa um outro desenvolvedor, não o cliente final que adquire o sistema de aplicação). Se o módulo é uma classe única, a interface é simplesmente o conjunto das funções-membro public: e as funções friend. Se o módulo é um grupo compacto de classes, a interface pode incluir várias classes do módulo.

Projetar uma interface limpa e separar a interface da implementação, meramente permite ao usuário usar a interface. Mas encapsular (colocar em uma cápsula) a implementação força o usuário a usar a interface.

Infelizmente essa abordagem não suporta múltiplas instâncias dos dados, já que não há suporte direto para tornar static múltiplas instâncias dos dados do módulo. Se múltiplas instâncias fossem necessárias em C, os programadores tipicamente usavam C struct. Mas infelizmente C struct não suporta encapsulamento. Isso exacerbava o equilíbrio entre segurança (ocultar informação) e usabilidade (múltiplas instâncias).

Em C++, você pode ter tanto múltiplas instâncias quanto encapsulamento usando uma classe. A parte public: da classe contém a interface da classe, que normalmente consiste das funções-membro public: e suas funções friend. As partes private: e/ou protected: da classe contém a implementação da classe, que é onde tipicamente os dados existem.

Um programador ver as partes private: e/ou protected: de sua classe não significa necessariamente violação do encapsulamento, desde que ele não escreva códigos que dependam do que ele vê nas partes internas de sua classe.

Em outras palavras, encapsulamento não impede que as pessoas tomem conhecimento das definições internas de sua classe, o que encapsulamento faz é evitar que código escrito por outras pessoas dependam de definições internas à sua classe. A sua empresa não quer evitar os custos de manutenção decorrentes dos que as pessoas ouvem ou vêm, o que ela quer é evitar custos de manutenção sobre os códigos que as pessoas produzem. O que você sabe sobre as partes internas de uma classe não aumenta os custos de manutenção. Estes custos são dependentes da qualidade da interface e da qualidade da implementação das classes.

Além do mais, isso não chega mesmo a ser um problema. Eu não conheço nenhum programador que tenha, intencionalmente, acessado as partes private: de uma classe. "Minha recomendação, nesse caso, seria trocar o programador, não a maneira de codificar" [James Kanke, kanze@gabi-soft.com, citado sob permissão]

struct e class são funcionalmente equivalentes.

Ok. Basta dessa estridente conversa técnica. Intuitivamente, a maioria dos desenvolvedores faz uma grande distinção entre uma class e uma struct. Uma struct simplesmente se comporta como uma pilha aberta de bits, pouco direcionada para o encapsulamento ou para a funcionalidade. Uma class se comporta como um responsável membro de uma sociedade com serviços inteligentes, uma forte barreira de encapsulamento, e uma interface bem definida. Já que essa é uma noção comum a muitas pessoas, você deveria usar struct se  você tem uma classe que tem muito poucos métodos e  tem dados public. (Tais classes realmente existem, mesmo em sistemas muito bem projetados). Em todos os outros casos você deveria usar a palavra-chave class.