Classe (programação de computador)

Na programação orientada a objetos, uma classe é um modelo de código de programa extensível para criar objetos, fornecendo valores iniciais para estado (variáveis de membro) e implementações de comportamento (funções ou métodos de membro). Em muitas linguagens, o nome da classe é usado como o nome da classe (o próprio modelo), o nome do construtor padrão da classe (uma sub-rotina que cria objetos) e como o tipo de objetos gerados pela instanciação da classe; esses conceitos distintos são facilmente confundidos. Embora, ao ponto de confundir, pode-se argumentar que é uma característica inerente a uma linguagem por causa de sua natureza polimórfica e por que essas linguagens são tão poderosas, dinâmicas e adaptáveis para uso em comparação com linguagens sem polimorfismo presente. Assim, eles podem modelar sistemas dinâmicos (ou seja, o mundo real, aprendizado de máquina, IA) com mais facilidade.

Quando um objeto é criado por um construtor da classe, o objeto resultante é chamado de instância da classe, e as variáveis de membro específicas do objeto são chamadas de variáveis de instância, para contrastar com as variáveis de classe compartilhadas na classe.

Em certas linguagens, as classes são, na verdade, apenas um recurso de tempo de compilação (novas classes não podem ser declaradas em tempo de execução), enquanto em outras linguagens as classes são cidadãos de primeira classe e geralmente são eles próprios objetos (normalmente do tipo Classe ou similar). Nessas linguagens, uma classe que cria classes dentro de si é chamada de metaclasse.

Classe x tipo

Em seu uso mais casual, as pessoas costumam se referir à "classe" de um objeto, mas estritamente falando, os objetos têm tipo: a interface, ou seja, os tipos de variáveis de membro, as assinaturas de funções de membro (métodos) e as propriedades que satisfazem. Ao mesmo tempo, uma classe possui uma implementação (especificamente a implementação dos métodos) e pode criar objetos de um determinado tipo, com uma determinada implementação. Nos termos da teoria de tipos, uma classe é uma implementação—uma estrutura de dados concreta e uma coleção de sub-rotinas—enquanto um tipo é uma interface. Classes diferentes (concretas) podem produzir objetos do mesmo tipo (abstrato) (dependendo do sistema de tipos); por exemplo, o tipo Stack pode ser implementado com duas classes – SmallStack (rápido para pequenas pilhas, mas escala mal) e ScalableStack (escala bem, mas alta sobrecarga para pilhas pequenas). Da mesma forma, uma determinada classe pode ter vários construtores diferentes.

Os tipos de classe geralmente representam substantivos, como uma pessoa, lugar ou coisa, ou algo nominalizado, e uma classe representa uma implementação deles. Por exemplo, um tipo Banana pode representar as propriedades e funcionalidades das bananas em geral, enquanto o tipo ABCBanana e XYZBanana representariam maneiras de produzir bananas (digamos, fornecedores de banana ou estruturas de dados e funções para representar e desenhar bananas em um videogame). A classe ABCBanana poderia então produzir bananas específicas: instâncias da classe ABCBanana seriam objetos do tipo Banana. Freqüentemente, apenas uma única implementação de um tipo é fornecida; nesse caso, o nome da classe geralmente é idêntico ao nome do tipo.

Design e implementação

As classes são compostas por constituintes estruturais e comportamentais. Linguagens de programação que incluem classes como uma construção de programação oferecem suporte para vários recursos relacionados a classes, e a sintaxe necessária para usar esses recursos varia muito de uma linguagem de programação para outra.

Estrutura

Notação UML para classes

Uma classe contém descrições de campos de dados (ou propriedades, campos, membros de dados ou atributos). Geralmente, são tipos e nomes de campos que serão associados a variáveis de estado no tempo de execução do programa; essas variáveis de estado pertencem à classe ou a instâncias específicas da classe. Na maioria das linguagens, a estrutura definida pela classe determina o layout da memória utilizada por suas instâncias. Outras implementações são possíveis: por exemplo, objetos em Python usam contêineres de valores-chave associativos.

Algumas linguagens de programação, como Eiffel, suportam a especificação de invariantes como parte da definição da classe e as aplicam por meio do sistema de tipos. O encapsulamento do estado é necessário para poder impor as invariantes da classe.

Comportamento

O comportamento da classe ou de suas instâncias é definido usando métodos. Os métodos são sub-rotinas com a capacidade de operar em objetos ou classes. Essas operações podem alterar o estado de um objeto ou simplesmente fornecer maneiras de acessá-lo. Existem muitos tipos de métodos, mas o suporte para eles varia entre os idiomas. Alguns tipos de métodos são criados e chamados pelo código do programador, enquanto outros métodos especiais — como construtores, destruidores e operadores de conversão — são criados e chamados pelo código gerado pelo compilador. Uma linguagem também pode permitir que o programador defina e chame esses métodos especiais.

O conceito de interface de classe

Cada classe implementa (ou realiza) uma interface fornecendo estrutura e comportamento. A estrutura consiste em dados e estado, e o comportamento consiste em código que especifica como os métodos são implementados. Há uma distinção entre a definição de uma interface e a implementação dessa interface; no entanto, essa linha é confusa em muitas linguagens de programação porque as declarações de classe definem e implementam uma interface. Algumas linguagens, no entanto, fornecem recursos que separam interface e implementação. Por exemplo, uma classe abstrata pode definir uma interface sem fornecer implementação.

As linguagens que suportam a herança de classe também permitem que as classes herdem interfaces das classes das quais são derivadas.

Por exemplo, se "classe A" herda da "classe B" e se "classe B" implementa a interface "interface B" então "classe A" também herda a funcionalidade (declaração de constantes e métodos) fornecida pela "interface B".

Em linguagens que suportam especificadores de acesso, a interface de uma classe é considerada o conjunto de membros públicos da classe, incluindo métodos e atributos (através de métodos getter e setter implícitos); quaisquer membros privados ou estruturas de dados internas não devem ser dependentes de código externo e, portanto, não fazem parte da interface.

A metodologia de programação orientada a objetos dita que as operações de qualquer interface de uma classe devem ser independentes umas das outras. Isso resulta em um design em camadas onde os clientes de uma interface usam os métodos declarados na interface. Uma interface não exige que os clientes invoquem as operações de uma interface em qualquer ordem específica. Essa abordagem tem o benefício de que o código do cliente pode assumir que as operações de uma interface estão disponíveis para uso sempre que o cliente tiver acesso ao objeto.

Exemplo

Os botões na frente do seu aparelho de televisão são a interface entre você e a fiação elétrica do outro lado de sua caixa de plástico. Você pressiona o botão "power" botão para ligar e desligar a televisão. Neste exemplo, sua televisão em particular é a instância, cada método é representado por um botão, e todos os botões juntos compõem a interface (outras televisões do mesmo modelo que a sua teriam a mesma interface). Em sua forma mais comum, uma interface é uma especificação de um grupo de métodos relacionados sem qualquer implementação associada dos métodos.

Um aparelho de televisão também tem uma miríade de atributos, como o tamanho e se suporta cor, que juntos compõem sua estrutura. Uma classe representa a descrição completa de uma televisão, incluindo seus atributos (estrutura) e botões (interface).

Obter o número total de televisores fabricados pode ser um método estático da classe television. Esse método está claramente associado à classe, mas está fora do domínio de cada instância individual da classe. Um método estático que encontra uma instância específica fora do conjunto de todos os objetos de televisão é outro exemplo.

Acessibilidade para membros

O seguinte é um conjunto comum de especificadores de acesso:

• Privado (ou classe privada) restringe o acesso à própria classe. Apenas os métodos que fazem parte da mesma classe podem acessar membros privados.
• Protegido (ou classe protegida) permite que a própria classe e todas as suas subclasses acessem o membro.
• Público significa que qualquer código pode acessar o membro pelo seu nome.

Embora muitas linguagens orientadas a objetos suportem os especificadores de acesso acima, sua semântica pode ser diferente.

O projeto orientado a objetos usa os especificadores de acesso em conjunto com o projeto cuidadoso de implementações de métodos públicos para impor invariantes de classe—restrições no estado dos objetos. Um uso comum de especificadores de acesso é separar os dados internos de uma classe de sua interface: a estrutura interna torna-se privada, enquanto métodos acessadores públicos podem ser usados para inspecionar ou alterar esses dados privados.

Os especificadores de acesso não controlam necessariamente a visibilidade, pois mesmo os membros privados podem ser visíveis para o código externo do cliente. Em alguns idiomas, um membro inacessível, mas visível, pode ser referido em tempo de execução (por exemplo, por um ponteiro retornado de uma função de membro), mas uma tentativa de usá-lo referindo-se ao nome do membro do código do cliente será impedido pelo verificador de tipo.

As várias linguagens de programação orientadas a objetos reforçam a acessibilidade e a visibilidade dos membros em vários graus e, dependendo do sistema de tipo da linguagem e das políticas de compilação, aplicadas em tempo de compilação ou em tempo de execução. Por exemplo, a linguagem Java não permite a compilação do código cliente que acessa os dados privados de uma classe. Na linguagem C++, os métodos privados são visíveis, mas não acessíveis na interface; no entanto, eles podem se tornar invisíveis declarando explicitamente classes totalmente abstratas que representam as interfaces da classe.

Alguns idiomas apresentam outros esquemas de acessibilidade:

• Acessibilidade de instância vs classe: Suporte de Ruby instância-privado e proteção da instância especifiers de acesso em vez de classe privada e de classe protegida, respectivamente. Eles diferem em que restringem o acesso com base na própria instância, em vez da classe da instância.
• Amigo: C++ suporta um mecanismo onde uma função explicitamente declarada como uma função amiga da classe pode acessar os membros designados como privados ou protegidos.
• Baseado no caminho: Java suporta restringir o acesso a um membro dentro de um pacote Java, que é o caminho lógico do arquivo. No entanto, é uma prática comum ao estender um framework Java para implementar classes no mesmo pacote que uma classe-quadro para acessar membros protegidos. O arquivo de origem pode existir em um local completamente diferente, e pode ser implantado em um diferente. arquivo jar, ainda estar no mesmo caminho lógico no que diz respeito à JVM.

Relacionamentos entre classes

Além do design de classes independentes, as linguagens de programação podem oferecer suporte ao design de classe mais avançado com base nos relacionamentos entre as classes. Os recursos de design de relacionamento entre classes comumente fornecidos são composicionais e hierárquicos.

Composição

As classes podem ser compostas por outras classes, estabelecendo assim um relacionamento de composição entre a classe envolvente e suas classes incorporadas. O relacionamento de composição entre classes também é comumente conhecido como relacionamento has-a. Por exemplo, uma classe "Carro" pode ser composto e conter uma classe "Engine". Portanto, um Carro possui um Motor. Um aspecto da composição é a contenção, que é o fechamento de instâncias de componentes pela instância que as possui. Se um objeto envolvente contiver instâncias de componentes por valor, os componentes e seu objeto envolvente terão um tempo de vida semelhante. Se os componentes estiverem contidos por referência, eles podem não ter um tempo de vida semelhante. Por exemplo, em Objective-C 2.0:

@interface Carro: NSObject@property NSString *Nome;@property Motor *motor@property NSARray *pneus;@end

Esta classe Car tem uma instância de NSString (um objeto string), Engine e NSArray (um objeto de matriz).

Hierárquico

As classes podem ser derivadas de uma ou mais classes existentes, estabelecendo assim um relacionamento hierárquico entre as classes derivadas (classes base, classes pais ou superclasses) e a classe derivada (classe filha ou subclasse). O relacionamento da classe derivada com as classes derivadas é comumente conhecido como um relacionamento é-um. Por exemplo, uma classe 'Botão' pode ser derivado de uma classe 'Control'. Portanto, um Button é um Controle. Membros estruturais e comportamentais das classes pai são herdados pela classe filha. Classes derivadas podem definir membros estruturais adicionais (campos de dados) e membros comportamentais (métodos) além daqueles que eles herdam e são, portanto, especializações de suas superclasses. Além disso, classes derivadas podem substituir métodos herdados se o idioma permitir.

Nem todos os idiomas suportam herança múltipla. Por exemplo, Java permite que uma classe implemente várias interfaces, mas apenas herde de uma classe. Se herança múltipla for permitida, a hierarquia é um grafo acíclico direcionado (ou DAG para abreviar), caso contrário, é uma árvore. A hierarquia tem classes como nós e relacionamentos de herança como links. Classes no mesmo nível são mais prováveis de serem associadas do que classes em níveis diferentes. Os níveis dessa hierarquia são chamados de camadas ou níveis de abstração.

Exemplo (código Objective-C 2.0 simplificado, do iPhone SDK):

@interface UIRSponder: NSObject //...@interface UIView: UIRSponder //...@interface UIScroll Visualização: UIView //...@interface UITableView: UIScroll Visualização //...

Neste exemplo, um UITableView é um UIScrollView é um UIView é um UIResponder é um NSObject.

Definições de subclasse

Conceitualmente, uma superclasse é um superconjunto de suas subclasses. Por exemplo, uma hierarquia de classe comum envolveria GraphicObject como uma superclasse de Retângulo e Elipse, enquanto Quadrado seria uma subclasse de Retângulo. Todas essas são relações de subconjunto também na teoria dos conjuntos, ou seja, todos os quadrados são retângulos, mas nem todos os retângulos são quadrados.

Um erro conceitual comum é confundir uma relação parte de com uma subclasse. Por exemplo, um carro e um caminhão são tipos de veículos e seria apropriado modelá-los como subclasses de uma classe de veículos. Entretanto, seria um erro modelar os componentes do carro como relações de subclasse. Por exemplo, um carro é composto de motor e carroceria, mas não seria apropriado modelar motor ou carroceria como uma subclasse de carro.

Na modelagem orientada a objetos, esses tipos de relações são normalmente modelados como propriedades do objeto. Neste exemplo, a classe Car teria uma propriedade chamada peças. partes seriam digitadas para conter uma coleção de objetos, como instâncias de Body, Engine , Pneus, etc. As linguagens de modelagem de objetos, como UML, incluem recursos para modelar vários aspectos de "parte de" e outros tipos de relações – dados como a cardinalidade dos objetos, restrições nos valores de entrada e saída, etc. Essas informações podem ser utilizadas por ferramentas de desenvolvedor para gerar código adicional além das definições básicas de dados para os objetos, como verificação de erros em métodos get e set.

Uma questão importante ao modelar e implementar um sistema de classes de objetos é se uma classe pode ter uma ou mais superclasses. No mundo real com conjuntos reais, seria raro encontrar conjuntos que não se cruzassem com mais de um outro conjunto. No entanto, enquanto alguns sistemas como Flavors e CLOS fornecem uma capacidade para mais de um pai fazer isso em tempo de execução, introduz uma complexidade que muitos na comunidade orientada a objetos consideram antitética aos objetivos de usar classes de objetos em primeiro lugar. Entender qual classe será responsável pelo tratamento de uma mensagem pode ser complexo ao lidar com mais de uma superclasse. Se usado descuidadamente, esse recurso pode introduzir algumas das mesmas complexidades do sistema e classes de ambigüidade que foram projetadas para evitar.

A maioria das linguagens orientadas a objetos modernas, como Smalltalk e Java, requerem herança única em tempo de execução. Para essas linguagens, a herança múltipla pode ser útil para modelagem, mas não para uma implementação.

Entretanto, os objetos de aplicativo da Web semântica possuem várias superclasses. A volatilidade da Internet exige esse nível de flexibilidade e os padrões de tecnologia, como o Web Ontology Language (OWL), foram projetados para suportá-la.

Um problema semelhante é se a hierarquia de classes pode ou não ser modificada em tempo de execução. Linguagens como Flavours, CLOS e Smalltalk suportam esse recurso como parte de seus protocolos de meta-objetos. Como as próprias classes são objetos de primeira classe, é possível fazer com que elas alterem dinamicamente sua estrutura, enviando-lhes as mensagens apropriadas. Outras linguagens que se concentram mais em tipagem forte, como Java e C++, não permitem que a hierarquia de classes seja modificada em tempo de execução. Os objetos da Web semântica têm a capacidade de alterar as classes em tempo de execução. O racional é semelhante à justificativa para permitir múltiplas superclasses, que a Internet é tão dinâmica e flexível que mudanças dinâmicas na hierarquia são necessárias para gerenciar essa volatilidade.

Ortogonalidade do conceito de classe e herança

Embora as linguagens baseadas em classes sejam comumente aceitas como suporte à herança, a herança não é um aspecto intrínseco do conceito de classes. Algumas linguagens, muitas vezes referidas como "linguagens baseadas em objeto", suportam classes, mas não suportam herança. Exemplos de linguagens baseadas em objeto incluem versões anteriores do Visual Basic.

Na análise orientada a objetos

Na análise orientada a objetos e na UML, uma associação entre duas classes representa uma colaboração entre as classes ou suas instâncias correspondentes. As associações têm direção; por exemplo, uma associação bidirecional entre duas classes indica que ambas as classes estão cientes de seu relacionamento. As associações podem ser rotuladas de acordo com seu nome ou finalidade.

Uma função de associação é dada no final de uma associação e descreve a função da classe correspondente. Por exemplo, um "assinante" função descreve a maneira como as instâncias da classe "Pessoa" participar de um "inscrever-se" associação com a classe "Revista". Além disso, uma "Revista" tem a "revista assinada" função na mesma associação. A multiplicidade de papéis da associação descreve quantas instâncias correspondem a cada instância da outra classe da associação. Multiplicidades comuns são "0..1", "1..1", "1..*" e "0..*", onde o "*" especifica qualquer número de instâncias.

Taxonomia de classes

Existem muitas categorias de classes, algumas das quais se sobrepõem.

Abstrato e concreto

Em uma linguagem que suporta herança, uma classe abstrata, ou classe base abstrata (ABC), é uma classe que não pode ser instanciada porque é rotulada como abstrata ou simplesmente especifica métodos abstratos (ou métodos virtuais). Uma classe abstrata pode fornecer implementações de alguns métodos e também pode especificar métodos virtuais por meio de assinaturas que devem ser implementadas por descendentes diretos ou indiretos da classe abstrata. Antes que uma classe derivada de uma classe abstrata possa ser instanciada, todos os métodos abstratos de suas classes pai devem ser implementados por alguma classe na cadeia de derivação.

A maioria das linguagens de programação orientadas a objetos permitem que o programador especifique quais classes são consideradas abstratas e não permite que elas sejam instanciadas. Por exemplo, em Java, C# e PHP, a palavra-chave abstract é usada. Em C++, uma classe abstrata é uma classe que possui pelo menos um método abstrato fornecido pela sintaxe apropriada nessa linguagem (uma função virtual pura na linguagem C++).

Uma classe que consiste apenas em métodos virtuais é chamada de Pure Abstract Base Class (ou Pure ABC) em C++ e também é conhecida como interface pelos usuários da linguagem. Outras linguagens, principalmente Java e C#, suportam uma variante de classes abstratas chamadas de interface por meio de uma palavra-chave na linguagem. Nessas linguagens, a herança múltipla não é permitida, mas uma classe pode implementar várias interfaces. Essa classe só pode conter métodos abstratos publicamente acessíveis.

Uma classe concreta é uma classe que pode ser instanciada, ao contrário das classes abstratas, que não podem.

Local e interno

Em algumas linguagens, as classes podem ser declaradas em escopos diferentes do escopo global. Existem vários tipos de tais classes.

Uma classe interna é uma classe definida dentro de outra classe. O relacionamento entre uma classe interna e sua classe recipiente também pode ser tratado como outro tipo de associação de classe. Uma classe interna geralmente não é associada a instâncias da classe envolvente nem instanciada junto com sua classe envolvente. Dependendo do idioma, pode ou não ser possível referir-se à classe de fora da classe delimitadora. Um conceito relacionado é tipos internos, também conhecido como tipo de dados internos ou tipo aninhado, que é uma generalização do conceito de classes internas. C++ é um exemplo de linguagem que suporta tanto classes internas quanto tipos internos (através de declarações typedef).

Outro tipo é uma classe local, que é uma classe definida dentro de um procedimento ou função. Isso limita as referências ao nome da classe dentro do escopo em que a classe é declarada. Dependendo das regras semânticas do idioma, pode haver restrições adicionais nas classes locais em comparação com as não locais. Uma restrição comum é não permitir que métodos de classe locais acessem variáveis locais da função delimitadora. Por exemplo, em C++, uma classe local pode se referir a variáveis estáticas declaradas dentro de sua função delimitadora, mas não pode acessar as variáveis automáticas da função.

Metaclasses

Metaclasses são classes cujas instâncias são classes. Uma metaclasse descreve uma estrutura comum de uma coleção de classes e pode implementar um padrão de projeto ou descrever tipos particulares de classes. As metaclasses são frequentemente usadas para descrever estruturas.

Em algumas linguagens, como Python, Ruby ou Smalltalk, uma classe também é um objeto; assim, cada classe é uma instância de uma metaclasse única que é construída na linguagem. O Common Lisp Object System (CLOS) fornece protocolos de metaobjetos (MOPs) para implementar essas classes e metaclasses.

Não subclassificável

As classes não subclassáveis permitem que os programadores criem classes e hierarquias de classes onde, em algum nível da hierarquia, é proibida a derivação adicional (uma classe autônoma também pode ser designada como não subclassável, impedindo a formação de qualquer hierarquia). Compare isso com classes abstratas, que implicam, encorajam e requerem derivação para serem usadas. Uma classe não subclassável é implicitamente concreta.

Uma classe não subclassável é criada declarando a classe como lacrado em C# ou como final em Java ou PHP. Por exemplo, String é designada como final.

As classes não subclassáveis podem permitir que um compilador (em linguagens compiladas) execute otimizações que não estão disponíveis para classes subclassáveis.

Aula aberta

Uma classe aberta é aquela que pode ser alterada. Normalmente, um programa executável não pode ser alterado pelos clientes. Os desenvolvedores geralmente podem alterar algumas classes, mas normalmente não podem alterar as padrão ou integradas. Em Ruby, todas as classes são abertas. No Python, as classes podem ser criadas em tempo de execução e todas podem ser modificadas posteriormente. As categorias Objective-C permitem que o programador adicione métodos a uma classe existente sem a necessidade de recompilar essa classe ou mesmo ter acesso ao seu código-fonte.

Misturas

Algumas linguagens têm suporte especial para mixins, embora em qualquer linguagem com herança múltipla um mixin seja simplesmente uma classe que não representa um relacionamento é-um-tipo. Mixins são normalmente usados para adicionar os mesmos métodos a várias classes; por exemplo, uma classe UnicodeConversionMixin pode fornecer um método chamado unicode_to_ascii quando incluída nas classes FileReader e WebPageScraper que não compartilham um pai comum.

Parcial

Em linguagens que suportam o recurso, uma classe parcial é uma classe cuja definição pode ser dividida em várias partes, em um único arquivo de código-fonte ou em vários arquivos. As partes são mescladas em tempo de compilação, tornando a saída do compilador a mesma de uma classe não parcial.

A principal motivação para a introdução de classes parciais é facilitar a implementação de geradores de código, como designers visuais. Caso contrário, é um desafio ou compromisso desenvolver geradores de código que possam gerenciar o código gerado quando ele é intercalado no código escrito pelo desenvolvedor. Usando classes parciais, um gerador de código pode processar um arquivo separado ou uma classe parcial granular dentro de um arquivo e, assim, é aliviado de intrincar o código gerado por meio de análise extensiva, aumentando a eficiência do compilador e eliminando o risco potencial de corromper o código do desenvolvedor. Em uma implementação simples de classes parciais, o compilador pode realizar uma fase de pré-compilação onde "unifica" todas as partes de uma classe parcial. Em seguida, a compilação pode prosseguir normalmente.

Outros benefícios e efeitos do recurso de classe parcial incluem:

• Permite a separação da interface e do código de implementação de uma classe de uma forma única.
• Eases navegação através de grandes classes dentro de um editor.
• Permite a separação de preocupações, de forma semelhante à programação orientada a aspectos, mas sem usar ferramentas extras.
• Permite que vários desenvolvedores trabalhem em uma única classe simultaneamente sem a necessidade de mesclar o código individual em um arquivo mais tarde.

Classes parciais existiram em Smalltalk sob o nome de Class Extensions por um tempo considerável. Com a chegada do.NET framework 2, a Microsoft introduziu classes parciais, com suporte em C# 2.0 e Visual Basic 2005. O WinRT também oferece suporte a classes parciais.

Exemplo em VB.NET

Este exemplo simples, escrito em Visual Basic.NET, mostra como partes da mesma classe são definidas em dois arquivos diferentes.

arquivo.vb

Parcial Classe Meu Deus! Privado Nome Como StringFim Classe

arquivo2.vb

Parcial Classe Meu Deus! Público Readonly Propriedade Nome() Como String Vai! Voltar Nome Fim Vai! Fim PropriedadeFim Classe

Quando compilado, o resultado é o mesmo como se os dois arquivos fossem escritos como um só, assim:

Classe Meu Deus! Privado Nome Como String Público Readonly Propriedade Nome() Como String Vai! Voltar Nome Fim Vai! Fim PropriedadeFim Classe

Exemplo em Objective-C

Em Objective-C, classes parciais, também conhecidas como categorias, podem até se espalhar por várias bibliotecas e executáveis, como no exemplo a seguir. Mas uma diferença fundamental é que as categorias do Objective-C podem sobrescrever as definições em outra declaração de interface e que as categorias não são iguais à definição de classe original (a primeira requer a última). Em vez disso, a classe parcial.NET não pode ter definições conflitantes e todas as definições parciais são iguais às outras.

Em Foundation, arquivo de cabeçalho NSData.h:

@interface NSData: NSObject- Não. (I)initWithContentsOfURL:(NSURL *)URL;//...@end

Na biblioteca fornecida pelo usuário, um binário separado da estrutura da Fundação, arquivo de cabeçalho NSData+base64.h:

#import @interface NSData (base64)- Não. (NSString *)Base64String;- Não. (I)initWithBase64String:(NSString *)Base64String;@end

E em um aplicativo, outro arquivo binário separado, arquivo de código-fonte main.m:

#import #import "NSData+base64.h"- Não. principal(- Não. Argc, Charlie. *Argv[]( se (Argc < 2) retorno ANEXO; NSString *fonte de alimentação = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Não.NSString string Com o CString:ArgvNão.1]] NSData *dados = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = [NSData Alocução] InitWithContentsOfURL:Não.NSURL URL Compartilhamento:fonte de alimentação]] NSLog(@"%@", Não.dados Base64String); retorno EXITSOS;?

O despachante encontrará ambos os métodos chamados na instância NSData e invocará ambos corretamente.

Ininstanciável

Classes não instanciáveis permitem que os programadores agrupem campos e métodos por classe que são acessíveis em tempo de execução sem uma instância da classe. De fato, a instanciação é proibida para esse tipo de classe.

Por exemplo, em C#, uma classe marcada como "estática" não pode ser instanciado, pode ter apenas membros estáticos (campos, métodos, outros), não pode ter construtores de instância e é lacrado.

Sem nome

Uma classe sem nome ou classe anônima é uma classe que não está vinculada a um nome ou identificador na definição. Isso é análogo a funções nomeadas versus funções não nomeadas.

Benefícios

Os benefícios de organizar o software em classes de objeto se enquadram em três categorias:

• Desenvolvimento rápido
• Facilidade de manutenção
• Reutilização de códigos e desenhos

As classes de objeto facilitam o desenvolvimento rápido porque diminuem a lacuna semântica entre o código e os usuários. Os analistas de sistema podem conversar com desenvolvedores e usuários usando essencialmente o mesmo vocabulário, falando sobre contas, clientes, faturas, etc. As classes de objetos geralmente facilitam o desenvolvimento rápido porque a maioria dos ambientes orientados a objetos vem com poderosas ferramentas de depuração e teste. Instâncias de classes podem ser inspecionadas em tempo de execução para verificar se o sistema está funcionando conforme o esperado. Além disso, em vez de obter despejos de memória principal, a maioria dos ambientes orientados a objetos interpretou os recursos de depuração para que o desenvolvedor possa analisar exatamente onde ocorreu o erro no programa e ver quais métodos foram chamados para quais argumentos e com quais argumentos.

As classes de objeto facilitam a manutenção por meio de encapsulamento. Quando os desenvolvedores precisam alterar o comportamento de um objeto, eles podem localizar a alteração apenas nesse objeto e em suas partes componentes. Isso reduz o potencial de efeitos colaterais indesejados de aprimoramentos de manutenção.

A reutilização de software também é um grande benefício do uso de classes Object. As classes facilitam a reutilização por meio de herança e interfaces. Quando um novo comportamento é necessário, ele geralmente pode ser alcançado criando uma nova classe e fazendo com que essa classe herde os comportamentos e dados padrão de sua superclasse e, em seguida, adapte algum aspecto do comportamento ou dados de acordo. A reutilização por meio de interfaces (também conhecidas como métodos) ocorre quando outro objeto deseja invocar (em vez de criar um novo tipo de) alguma classe de objeto. Esse método de reutilização remove muitos dos erros comuns que podem ocorrer no software quando um programa reutiliza o código de outro.

Representação em tempo de execução

Como um tipo de dados, uma classe geralmente é considerada uma construção em tempo de compilação. Uma linguagem ou biblioteca também pode suportar protótipos ou metaobjetos de fábrica que representam informações em tempo de execução sobre classes ou até mesmo representam metadados que fornecem acesso a recursos de reflexão e capacidade de manipular formatos de estrutura de dados em tempo de execução. Muitas linguagens distinguem esse tipo de informação de tipo de tempo de execução sobre classes de uma classe com base no fato de que a informação não é necessária em tempo de execução. Algumas linguagens dinâmicas não fazem distinções estritas entre construções de tempo de execução e de compilação e, portanto, podem não distinguir entre metaobjetos e classes.

Por exemplo, se Human é um metaobjeto representando a classe Person, então instâncias da classe Person podem ser criadas usando as facilidades do metaobjeto Human.