Como você chama classes sem métodos?

Como você chama classes sem métodos?

Por exemplo,

class A
{
  public string something;
  public int a;
}

Acima está uma classe sem nenhum método. Esse tipo de classe tem um nome especial?

Na maioria das vezes: um anti-padrão.

Por quê? Porque facilita a programação processual com classes "Operador" e estruturas de dados. Você separa dados e comportamento, o que não é exatamente bom OOP.

Muitas vezes: um DTO (objeto de transferência de dados)

Leia apenas estruturas de dados destinadas a trocar dados, derivados de um objeto de negócios / domínio.

Às vezes: apenas estrutura de dados.

Bem, às vezes, você só precisa ter essas estruturas para armazenar dados simples e simples e sem operações. Mas então eu não usaria campos públicos, mas acessadores (getters e setters).

Eu chamaria isso structou recordporque é usado para armazenamento de dados e isso é muito comum em linguagens como Cvocê pode ver lá: struct (linguagem de programação C) . Então, pessoalmente, eu preferiria usar structuma classe em vez de uma classe mais adequada e legível:

struct A
{
  public string something;
  public int a;
}

Geralmente eles são usados ​​como DTOs (Data Transfer Object), como os demais.

Eles são conhecidos como Objetos Antigos Simples (PO_Os), onde o espaço em branco é Java ou C ou CIL ou qualquer outro idioma que você esteja usando.

Se estiverem sendo usados ​​como blocos de dados simples para comunicação, eles poderão ser conhecidos como DTOs ( Data Transfer Objects ).

Se eles estão representando alguns dados fornecidos externamente, eles podem ser conhecidos como Entidades .

Eu chamaria essa classe de detentor de dados mutáveis ​​e, às vezes, usava um formulário genérico:

class DataHolder<T>
{
   public T dat;
}

Observe que o encapsulamento datem uma propriedade prejudicará o desempenho e não oferecerá nenhum benefício, pois não há nada que um acessador de propriedade possa fazer (exceto ler / gravar o campo) que não interrompa algumas implementações. Além disso, pode ser necessário usar Interlockedmétodos com dat(ou, se for uma estrutura, com seus campos), mas isso não seria possível se datestivesse envolvido em uma propriedade.

Observe que, embora os titulares de dados mutáveis ​​possam ser úteis para tipos (mutáveis ​​ou não) que precisam reter dados, eles não podem ser usados ​​com segurança para o intercâmbio de dados da mesma maneira que os tipos imutáveis. Por exemplo, uma declaração como:

myData = myCollection.GetData(myKey);

teria um significado claro se GetDataretornasse um tipo de classe imutável ou uma estrutura ("mutável" ou não) que não contivesse referências a dados mutáveis. Se ele retornasse um objeto de classe mutável, no entanto, não seria claro se alguma alteração nesse objeto seria consistentemente ignorada pela coleção subjacente, resultaria consistentemente em atualizações limpas ou causaria algum comportamento incômodo ou imprevisível que não encontraria nenhuma descrição.

Se alguém desejasse que uma coleção retornasse dados em um objeto mutável, o paradigma correto geralmente seria algo como:

var myData = new WhateverType();
myCollection.GetData(myKey, myData);
myData.ModifySomehow();
myCollection.StoreData(myKey, myData);

Usando essa abordagem, há uma implicação clara que GetDatafará myDatacom que os dados da coleção sejam preenchidos, mas myCollectionnão seria esperado que ele mantivesse uma referência a ela assim que a função estivesse concluída, nem a utilizaria para qualquer outro propósito. StoreDatada mesma forma, copiava as informações myDatapara sua própria estrutura de dados interna sem manter uma referência. Observe que uma vantagem dessa abordagem é que, se o código do cliente estiver lendo muitos itens de dados em um loop, ele poderá criar com segurança uma instância myDatafora do loop e, em seguida, reutilizá-la sempre. Da mesma forma, myCollectionpode ser possível reutilizar a instância do objeto associada à chave (copiando dados da instância passada) sem precisar criar uma nova instância.

Dependendo do contexto, eu os chamo de Entidades. Nos meus aplicativos de negócios chatos, eles geralmente mapeiam 1: 1 para o meu DER.

Eu chamaria isso de Schema.

Isso abrange vários usos, como representar uma tabela de banco de dados, um registro desserializado ou um DTO, etc.