Most of the time: An anti pattern.

Why? Because it faciliates procedural programming with “Operator” classes and data structures. You separate data and behaviour which isn’t exactly good OOP.

Often times: A DTO (Data Transfer Object)

Read only datastructures meant to exchange data, derived from a business/domain object.

Sometimes: Just data structure.

Well sometimes, you just gotta have those structures to hold data that is just plain and simple and has no operations on it. But then I wouldn’t use public fields but accessors (getters and setters).

I’d call it struct or record because it is used for data storage and this is very common to languages like C as you can see there: struct (C programming language). So personally I would prefer use a struct instead of a class that is more suitable and readable:

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

Usually they are used as DTOs (Data Transfer Object) as said the others.

These are known as Plain Old __ Objects (PO_Os) where the blank is Java or C or CIL, or whatever language you’re using.

If they’re being used as simple data blocks for communication, then they can be known as Data Transfer Objects (DTOs).

If they’re representing some externally provided data, they can be known as Entities.

I would call such a class a mutable data holder, and have sometimes used a generic form:

class DataHolder<T>
{
   public T dat;
}

Note that wrapping dat within a property will degrade performance and offer no benefit, since there’s nothing that a property accessor could do (other than read/write the field) which wouldn’t break some implementations. Further, it may be necessary to use Interlocked methods with dat (or, if it’s a struct, with fields thereof), but that wouldn’t be possible if dat were wrapped in a property.

Note that while mutable data holders may be useful for types (mutable or not) which need to hold data, they cannot safely be used for data interchange in the same way that immutable types would. For example, a statement like:

myData = myCollection.GetData(myKey);

would have a clear meaning if GetData returned an immutable class type or a struct (“mutable” or not) which did not contain references to mutable data. If it returned a mutable class object, however, it would be unclear whether any changes to that object would consistently be ignored by the underlying collection, consistently result in clean updates to it, or cause some irksome or unpredictable behavior meeting neither description.

If one wished to have a collection return data in a mutable object, the correct paradigm would often be something like:

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

Using that approach, there is a clear implication that GetData will cause myData to be populated with data from the collection, but myCollection would not be expected to keep a reference to it once the function was complete, nor would it use it for any other purpose. StoreData would likewise copy information myData to its own internal data structure without keeping a reference. Note that one advantage of this approach is that if the client code will be reading many data items within a loop, it may safely create one instance of myData outside the loop, and then reuse that same instance every time through. Likewise, myCollection may be able to reuse the object instance associated with the key (copying data from the passed-in instance) without having to create a new instance.

Depending on the context, I call them Entities. On my boring business applications, they usually map 1:1 to my DER.

I would call it a Schema.

This covers multiple uses such as representing a database table, or a deserialised record, or a DTO, etc