¿Cómo llamas a las clases sin métodos?

¿Cómo llamas a las clases sin métodos?

Por ejemplo,

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

Arriba hay una clase sin ningún método. ¿Este tipo de clase tiene un nombre especial?

La mayoría de las veces: un anti patrón.

¿Por qué? Porque facilita la programación de procedimientos con clases "Operador" y estructuras de datos. Separa datos y comportamientos que no son exactamente buenos OOP.

Muchas veces: un DTO (objeto de transferencia de datos)

Estructuras de datos de solo lectura destinadas a intercambiar datos, derivados de un objeto de negocio / dominio.

A veces: solo estructura de datos.

Bueno, a veces, solo tienes que tener esas estructuras para contener datos que sean simples y simples y que no tengan operaciones. Pero entonces no usaría campos públicos sino accesores (captadores y establecedores).

Lo llamaría structo recordporque se usa para el almacenamiento de datos y esto es muy común en lenguajes Ccomo se puede ver allí: struct (lenguaje de programación C) . Así que personalmente preferiría usar structuna clase en lugar de una que sea más adecuada y legible:

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

Por lo general, se usan como DTO (objeto de transferencia de datos) como se dijo en los demás.

Estos se conocen como Objetos __ simples (PO_Os) donde el espacio en blanco es Java o C o CIL, o cualquier lenguaje que esté utilizando.

Si se están utilizando como simples bloques de datos para la comunicación, entonces pueden conocerse como Objetos de transferencia de datos (DTO).

Si representan algunos datos proporcionados externamente, pueden conocerse como Entidades .

Llamaría a esa clase un titular de datos mutable, y a veces he usado un formulario genérico:

class DataHolder<T>
{
   public T dat;
}

Tenga en cuenta que el ajuste datdentro de una propiedad degradará el rendimiento y no ofrecerá ningún beneficio, ya que no hay nada que pueda hacer un descriptor de acceso a la propiedad (aparte de leer / escribir el campo) que no rompa algunas implementaciones. Además, puede ser necesario usar Interlockedmétodos con dat(o, si se trata de una estructura, con campos de los mismos), pero eso no sería posible si datestuviese envuelto en una propiedad.

Tenga en cuenta que si bien los titulares de datos mutables pueden ser útiles para los tipos (mutables o no) que necesitan contener datos, no se pueden usar de forma segura para el intercambio de datos de la misma manera que lo harían los tipos inmutables. Por ejemplo, una declaración como:

myData = myCollection.GetData(myKey);

tendría un significado claro si se GetDatadevuelve un tipo de clase inmutable o una estructura ("mutable" o no) que no contiene referencias a datos mutables. Sin embargo, si devuelve un objeto de clase mutable, no estaría claro si la colección subyacente ignoraría consistentemente cualquier cambio en ese objeto, si daría como resultado actualizaciones limpias o si causaría algún comportamiento molesto o impredecible que no cumpla con ninguna descripción.

Si se desea que una colección devuelva datos en un objeto mutable, el paradigma correcto a menudo sería algo como:

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

Usando ese enfoque, existe una clara implicación que GetDatahará myDataque se llenen de datos de la colección, pero myCollectionno se esperaría que mantuviera una referencia a ella una vez que se completara la función, ni la usaría para ningún otro propósito. StoreDataasimismo, copiaría información myDataa su propia estructura interna de datos sin mantener una referencia. Tenga en cuenta que una ventaja de este enfoque es que si el código del cliente leerá muchos elementos de datos dentro de un ciclo, puede crear de manera segura una instancia myDatafuera del ciclo y luego reutilizar esa misma instancia cada vez. Del mismo modo, myCollectionpuede reutilizar la instancia de objeto asociada con la clave (copiando datos de la instancia transferida) sin tener que crear una nueva instancia.

Dependiendo del contexto, los llamo entidades. En mis aplicaciones comerciales aburridas, generalmente asignan 1: 1 a mi DER.

Yo lo llamaría a Schema.

Esto cubre múltiples usos, como la representación de una tabla de base de datos, o un registro deserializado, o un DTO, etc.