I am studying the programming language Kotlin, and I just came across the idea of a Data Class. I have a background in Java programming where classes can have fields and methods. I have heard programmers calling a class that contains only fields and no methods, as a Value Class. Also, I am familiar with the idea of Structures in C++ which to my knowledge, typically contain only fields.

Question #1: I therefore wondered about classes that contain only methods. Based on my Java background, it seems to me that it would probably be a static utility class containing only static methods. Also, since interfaces in Java 9 can contain default methods, you could have a method-only structure with interfaces. But what is the term that best describes this style of method-only classes?

Question #2: I wondered also about classes that contains both fields and methods. How are these called? Is there a more specific term, other than just Class or Standard Class, in contrast to Value Class and method-only classes.

Remark: I am not looking for terms that are programming language specific, but rather for generally accepted terms that apply across programming languages.


Dyad Class: class that contains both methods and fields.

Action Class: class that contains only methods, and no fields.

Data Class: class that contains only fields, and no methods.

  • 4
    One is called a class, and the other is also called a class. – gnasher729 Jul 10 '20 at 7:04
  • 1
    Hi Steve. I dared to streamline your question to regroup your 2 questions in two concise blocks. I also added that, you were looking for a term to make the difference with field-only and method-only classes in order to clarify the meaning of your original question. I hope I didn't remove anything important. – Christophe Jul 10 '20 at 19:32
  • 1
    By the way C++ structures are not field only. C++ structures are full classes, except that their members are public by default. – Christophe Jul 10 '20 at 19:35
  • @gnasher729, by saying this, are you taking the position that there shouldn't be names for classes based on their structure, as implied by my 2 questions? I feel that it would be helpful during design and during coding to know what the structure of a certain class would be, as that structure directly relates to its end use. If the designer says "use a value class to represent customer data", or "use a standard class to represent individual customers" then the coders will know not to use a method class to represent customer behavior, since that will be found in the requested method class. – Steve T Jul 11 '20 at 15:25
  • 1
    A class that has no methods today, may have one method tomorrow after someone refactors it, so... – Tulains Córdova Jul 12 '20 at 17:33

Question #1: what is the name of a class that contains only methods?


Question #2: what is the name of a class that contains both fields and methods?


These "names" (really, they're more like descriptions) come from the idea that the class fields can be thought of as an object's state. No fields, no state.

a static method -> no instance state.

A static method has no access to instance state. This is true but some people get confused and think that means you make a method static when it uses no instance state. Such people are pointing the implication arrow in the wrong direction. Besides, that thinking ignores the polymorphic power of non-static (dynamic) methods.

An object is a bag of functions that move around together. When it's properly encapsulated the outside world has no idea if it has state or not. It's really nobody else's business. Forcing the interface to change when state is added or removed violates the privacy of the class. Keep your nosy nose outta my privates.

The most famous example of a stateless object is the Gang of Fours Null Object Pattern. It's used to disable features by configuration rather than business logic. The null object follows some set interface but is packed with methods that quietly do nothing. Doing nothing doesn't require state.

Now some might point to examples of static methods like Math.pow() but remember, that's coming from a library. Your own codebase is a much more wild place. Don't pretend you're writing a library if you aren't.

From a design point of view there are two reasons to group methods together:

  1. They use the same fields
  2. They change together

Don't just focus on 1.

  • Classes that have only fields, and classes that have both fields and methods, are both stateful. But I am hoping to arrive at a name that differentiates between these. Also, enumerations are stateful, but they can exist without either fields or methods. I very much like what you have said, but also I am wondering if you know of or can imagine names for these that abide by the restrictions implied in my 2 questions? – Steve T Jul 11 '20 at 15:40
  • 2
    @SteveT classes that contain only fields are method-less records. You called them a value class but that refers to how equality and hash methods are defined. If you want the answers to questions 1 and 2 to reflect this as well I’m afraid you end up with descriptions like “has fields” and “has methods”. And yes there are useful classes that have neither. What do they have? Names. – candied_orange Jul 11 '20 at 17:27
  • 2
    +1 for "When it's properly encapsulated the outside world has no idea if it has state or not. It's really nobody else's business. – Tulains Córdova Jul 12 '20 at 17:32

The first question should be: what is a class?

Wikipedia definition: "a class is an extensible program-code-template for creating objects"

So to answer your first question: what is the name of a class that contains only methods?

Technically you don't need a class for a code structure that contains only methods, because it's not necessary to instantiate the class (to create objects) to call these methods. In many OO-based languages you have no choice but to create a class though. Some languages allow you to mark the class and methods static, in order to prevent instantiation.

Classes without methods (data class) are often accompanied with classes that contain only methods. A typical name for these classes with nothing but methods is SometingService. So you will see a User data class and a UserService class that contain methods to do operations on User objects. This pattern is an OO-antipattern; to quote Martin Fowler: 'it's contrary to the basic idea of object-oriented design; which is to combine data and process together' (source).

Edit: @Christophe pointed out in the comments that there are valid scenario's for creating classes that contain only methods, but still require instantiation. For example the Strategy pattern encapsulates an algorithm which may not require state. In this context, it's mostly accidental that the class doesn't contain fieds.

As for your second question: what is the name of a class that contains both fields and methods?

A class.

  • 2
    We could of course start to argue about the validity of this wikipedia definition. But even if accepted, there is no conceptual contradiction between object and absence of attributes. The fact that there is no state doesn’t prevent the creation of an object. A very popular example is the strategy pattern, where a strategy object is injected into a context, mostly for its behavior and not for its state. Moreover the fact that there is, or there isn’t, a state to deliver a certain behavior is an implementation detail that is not of concern outside the boundaries of the class. – Christophe Jul 10 '20 at 7:43
  • 1
    @Christophe that's a fair observation. I edited my answer. – Rik D Jul 10 '20 at 8:40
  • 1
    Thanks. It’s more balanced now. +1 for the last two paragraphs that really go to the point and give your answer the flavor of a curiously recursive pattern ;-) – Christophe Jul 10 '20 at 9:17
  • 1
    @Christophe Staying with the Strategy Pattern example one could argue that there is state even in the absence of fields. The information concerning the runtime type of the object and enabling runtime polymorphism is a kind of state. Programmers just don’t think of it like that usually. – besc Jul 10 '20 at 14:06
  • 1
    @besc that is a very interesting argument. Your implementation and practical analyse complements the more abstract arguments. I think we all agree in the end that a class is more than just a bundle of “fields” and/or methods. – Christophe Jul 10 '20 at 14:29

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