Come si chiamano le classi senza metodi?

La maggior parte delle volte: un pattern anti.

Perché? Perché facilita la programmazione procedurale con classi e strutture dati "Operatore". Separate dati e comportamenti che non sono esattamente buoni OOP.

Spesso: un DTO (Data Transfer Object)

Leggere solo le strutture dati destinate allo scambio di dati, derivate da un oggetto business / dominio.

A volte: solo struttura dei dati.

A volte, devi solo avere quelle strutture per contenere i dati che sono semplici e semplici e non hanno operazioni su di esso. Ma poi non userei campi pubblici ma accessor (getter e setter).

Lo chiamerei struct o record perché è usato per l'archiviazione dei dati e questo è molto comune a linguaggi come C come puoi vedere qui: struct (linguaggio di programmazione C) . Quindi personalmente preferirei usare un struct invece di una classe più adatta e leggibile:

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

Di solito sono usati come DTO (Oggetto di trasferimento dati) come detto gli altri.

Questi sono noti come Plain Old __ Objects (PO_Os) dove lo spazio vuoto è Java o C o CIL, o qualsiasi altra cosa lingua che stai usando.

Se vengono utilizzati come semplici blocchi di dati per la comunicazione, possono essere conosciuti come Oggetti di trasferimento dati ( DTOs).

Se rappresentano alcuni dati forniti dall'esterno, possono essere conosciuti come Entità .

Definirei tale classe un titolare di dati mutevole e talvolta ho usato un modulo generico:

class DataHolder<T>
{
   public T dat;
}

Si noti che il wrapping di dat all'interno di una proprietà ridurrà le prestazioni e non offrirà alcun vantaggio, poiché non c'è nulla che un accessorio di proprietà possa fare (oltre a leggere / scrivere il campo) che non rompere alcune implementazioni. Inoltre, potrebbe essere necessario utilizzare i metodi Interlocked con dat (o, se si tratta di una struct, con i relativi campi), ma ciò non sarebbe possibile se dat fosse racchiuso in una proprietà.

Si noti che mentre i titolari di dati mutabili possono essere utili per tipi (mutabili o meno) che hanno bisogno di conservare dati, non possono essere usati in modo sicuro per lo scambio di dati nello stesso modo in cui sarebbero immutabili. Ad esempio, una frase come:

myData = myCollection.GetData(myKey);

avrebbe un significato chiaro se GetData ha restituito un tipo di classe immutabile o una struct ("mutable" o non) che non conteneva riferimenti a dati mutabili. Se restituisse un oggetto di classe mutabile, tuttavia, non sarebbe chiaro se eventuali modifiche a quell'oggetto venissero ignorate in modo coerente dalla raccolta sottostante, generassero in modo consistente aggiornamenti puliti o causassero un comportamento irrilevante o imprevedibile che non soddisfa nessuna descrizione.

Se si desidera che una raccolta restituisca dati in un oggetto mutabile, il paradigma corretto sarebbe spesso qualcosa del tipo:

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

Utilizzando questo approccio, vi è una chiara implicazione che GetData causerà myData da compilare con i dati dalla raccolta, ma myCollection non dovrebbe tenere un riferimento ad esso una volta che la funzione è stata completata, né lo userebbe per nessun altro scopo. StoreData copierà allo stesso modo le informazioni myData nella propria struttura dati interna senza mantenere un riferimento. Si noti che uno dei vantaggi di questo approccio è che se il codice client leggerà molti elementi di dati all'interno di un ciclo, può creare in modo sicuro un'istanza di myData all'esterno del ciclo e quindi riutilizzare sempre la stessa istanza. Allo stesso modo, myCollection potrebbe essere in grado di riutilizzare l'istanza dell'oggetto associata alla chiave (copia dei dati dall'istanza passata) senza dover creare una nuova istanza.

A seconda del contesto, li chiamo Entità. Nelle mie noiose applicazioni aziendali, di solito mappano 1: 1 al mio DER.

Lo chiamerei Schema .

Questo copre più usi come rappresentare una tabella di database, o un record deserializzato, o un DTO, ecc.