Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What do you call classes without methods?

For example,

class A
  public string something;
  public int a;

Above is a class without any methods. Does this type of class have a special name?

share|improve this question
A method-less class? –  ChaosPandion Aug 13 '12 at 16:39
The technical term is record or struct. –  Kilian Foth Aug 13 '12 at 17:18
A "property bag" –  Loki Astari Aug 13 '12 at 21:36
Kilian: I prefer "glorified struct" for the added connotation. –  Jason Aug 14 '12 at 18:20

5 Answers 5

up vote 21 down vote accepted

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).

share|improve this answer
I discourage everyone to do classes with only public getters/setters in java, it's brain-dead and some containers won't even run the setter/getter code (looking at Glassfish...), so either it's the default or you have a bug. I don't believe that OOP encapsulation was right, it turns out, most of the time, in most of the applications, DTOs are not only needed, but they're the most often used classes. So they're anything but antipatterns, I'd use the word "basic building blocks" instead. –  Aadaam Aug 13 '12 at 17:30
They're maybe an anti-pattern if you're in a strictly OO environment. For all the rest of the programming world, having data structures that are simple heterogeneous collections of fields is a clear benefit over the alternatives, and even encouraged in one well known OO mainstay. –  Telastyn Aug 13 '12 at 17:42
@Aadaam: You didn't get me right. A DTO isn't an antipattern. Sometimes those objects are perfectly fine iff they are DTOs! And when Glassfish doesn't look at getters and setters, that only means that glassfish isn't well written (although it's hard in java without builtin accessors). This code ain't braindead, it's useful boilerplate. –  Falcon Aug 13 '12 at 17:51
Quick, @Aadaam. Someone's setting a field to an invalid value, wreaking havoc when it's read later. Throw an exception so you can detect the culprit. The first time you have to do something like that for a public field used in 1,000 places, you'll wish for a setter. Public fields have their place, but the getter/setter paradigm is popular for good reason. –  Karl Bielefeldt Aug 13 '12 at 18:47
@KarlBielefeldt: in one glassfish version, I had a single exception in a setter code as a test (without conditions), which never executed. The property had a private variable and two public getters-and-setters. The container simply circumvented the setter. If something actually has an invalid value, personally I prefer type classes instead of primitive values, but maybe that's just me. –  Aadaam Aug 13 '12 at 18:51

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.

share|improve this answer
The problem with struct is, that "struct" is a keyword in many languages. C# for example treats structs as value types which have different semantics. This is also true for "record" in some languages (PL/SQL). –  Falcon Aug 13 '12 at 18:13

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.

share|improve this answer
You're thinking of PODs - a very different idea. POJOs explicitly include "business logic", but exclude dependencies on particular frameworks. –  Tom Hawtin - tackline Aug 13 '12 at 18:49
PODs are allowed to have methods, at least in C++. They just have to have only trivial constructors, destructor, copy constructors and assignment constructors, only public data members, no base classes and no virtual functions. Basically, they just have to be compatible with C structs. –  Dirk Holsopple Aug 16 '12 at 19:10

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);
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.

share|improve this answer

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

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.