Some languages such as Java and C# (since last I checked) require all functions to be inside of a class.

Some simple programs are procedural by design, such as command line tools. And requiring a class for the program does not make much sense.

What are any advantages to mandating class-oriented programming in a language?

  • 1
    $\begingroup$ C# permits single-file script-style source programs and has for years, and so does Java (in preview with JEP445, and you still need void main()), so I'm not sure those examples best illustrate what you're asking about. (It also seems like a pretty leading question at least) $\endgroup$
    – Michael Homer
    May 18, 2023 at 1:03
  • $\begingroup$ @MichaelHomer I thought I would get errors in Java such as Class, interface, or enum expected. $\endgroup$ May 18, 2023 at 1:08
  • $\begingroup$ You'd need to be running a prerelease Java 21, I think, and maybe turn on preview features. It's not as comprehensive as in C# because there is still an explicit main method. You can read the JEP though. $\endgroup$
    – Michael Homer
    May 18, 2023 at 1:11
  • 5
    $\begingroup$ "They require object-oriented programming. All must be part of a class." - Putting things into classes has nothing to do with object-oriented programming. Many things can be done inside a class that are extremely far from what the OOP paradigm intends; Java programs require an entry point, which is static (i.e. an instance of the containing class is not created) and is not required to create instances of any class (it can do everything with primitives if it wants). On the other hand, many languages comfortably support OOP paradigms while not using classes at all. $\endgroup$ May 18, 2023 at 1:16
  • $\begingroup$ If object-oriented programming were all about using classes, it would be called class-oriented programming instead. It's called object-oriented programming because it's about using objects. Classes are one possible implementation for representing the type of objects. (Javascript generally expects you to implement it using prototype-based inheritance, for example.) Many "proper OOP" languages hold that the classes themselves ought to be objects (as they are in, or example, Python); in Java this is not the case. $\endgroup$ May 18, 2023 at 1:18

4 Answers 4


For Java, the idea was to force OO from the ground up. As an added benefit, the class, together with its full name now formed a kind of namespacing for free functions.

Notes on namespacing

In the case of C++, there are two competing ways to namespace a function, you can either wrap a function in a namespace, or have it be a static method of a class. Similarly the same holds for globals and static member variables.

In fact, they are then called similarly some_namespace::free_function() vs FooClass::call_me().

This causes a design conundrum: when should we use namespace + free function and when should we use class + static method. Usage and performance is roughly equivalent after all.

This is avoided in Java, where only the latter would occur. The typical pattern (esp with early POJO java) would be to create abstract utility classes (today interfaces work too) to hold free functions, with this abstract class forming the namespace.

When designing a language that has both static methods and free functions, one would have to ask oneself: "how do I prevent users from being confused regarding how to distribute functions?".

In Zig, observing this tension between namespaced free function and static struct methods, made the language embrace using structs as namespaces, leading to novel behaviour such as "a file is a struct" in Zig. So Foo.call_me() and foo.call_me_too()

As a contrast, a similar observation for C3 led to the complete removal of static methods and static variables for types. In that language, there is then only some_namespace::free_function() and foo.call_me_too()


(Just playing devils advocate here, I don't actually like Java)

To more easily see and architect relationships

In a traditional, large scale software project as taught in my university, classes are the foundation of the design process. When starting a project, a team of architects will start dividing the problem into packages, modules and classes. The purpose of each class will be documented in detail as and UML diagrams will be drawn of the relationship between every class.

Only when detailed specifications have been finished will any developers start writing any code. Languages like Java and C# will match the provided diagrams very closely making this step a relatively easy task. The different kinds of relationships in UML map easily to classes, conversing is straightforwards.

When I did my internship we where expected to follow the same process but the language was JavaScript so trying to capture the logic in nice diagrams didn't work at all. The complexity of the relationships between functions make the diagrams a tangled mess. Hierarchical specifications don't work at all either.

Of course, the waterfall model of software development has fallen out of favor and with it the need for types of architecture that can be diagrammed and specified in detail. However, in the waterfall model Java-style class based architecture makes sense.

  • $\begingroup$ "When I did my internship we where expected to follow the same process but the language was JavaScript so trying to capture the logic in nice diagrams didn't work at all. The complexity of the relationships between functions make the diagrams a tangled mess." but that's not inherent to "using functions". It's down to design. You'd get the exact same situation if you use Java and you have God classes in the mix. You get the same tangled mess that is incomprehensible. $\endgroup$
    – VLAZ
    May 18, 2023 at 9:31
  • $\begingroup$ Generally a program has a lot more functions than classes, which makes them more tangled. Each function might have less relationships than a class but just by how many you typically have it makes it hard to organize and hard to write about in a technical design document $\endgroup$
    – mousetail
    May 18, 2023 at 9:38

It allows efficient division of labor

OOP has a heavy focus on objects implementing known interfaces. This has a major advantage for companies, large open source projects, and other organizations/projects involving many employees/contributors: the code can be efficiently divided up between a large number of people.

While this is also possible with more traditional non-OOP programming (e.g., assigning a function or module to someone), the ideas of functions being pure and code being divided into modules weren't as developed at the time that OOP became popular.


One reason is that it allows a single project to easily have multiple entry points ─ just declare main methods on multiple classes. This allows you to create multiple programs which share most of their code, without explicitly separating the shared code out into a separate library.

Another reason, for better or worse, is that it allows classes to serve multiple purposes. In traditional Java code (before modules and scripts were added to the language), classes were also used as namespaces and modules. Consider java.lang.Math, which is never instantiated and only has static methods. And, each class is compiled to its own .class file; since all methods belong to a class, this means it is easy to find the correct file at runtime when a not-yet-loaded method needs to be called. If methods could exist outside of classes, there would need to be some other mechanism for locating a compiled method on the filesystem.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .