tags:

views:

371

answers:

4

It seemed like this question should have been asked before, but searching found nothing.

I've always wondered what's the point of making us put every bit of code inside a class or interface. I seem to remember that there were some advantages to requiring a main() function like C, but nothing for classes. Languages like Python are, in a way, even more object oriented than Java since they don't have primitives, but you can put code wherever you want.

Is this some sort of "misinterpretation" of OOP? After all, you can write procedural code like you would in C and put it inside a class, but it won't be object oriented.

+3  A: 

I think the idea with Java was that a top-level class would represent a single unit of code that would be compiled to a separate .class file. The idea was that these discrete, self-contained units of code could then be easily shared and combined into many projects (just as a carpenter can combine basic parts like nuts, bolts, pieces of wood, etc., to make a variety of items). The class was seen as the smallest, most basic atomic unit, and thus everything should be a part of a class to make it easier to assemble larger programs from these parts.

One can argue that object-oriented programming's promise of easily composable code didn't work out very well, but back when Java was being designed, the goal of OOP was to create little units (classes) that could easily be combined to make unique programs.

I imagine C# had some of the same goals in mind.

mipadi
+9  A: 

I think the goal of requiring that everything is enclosed in classes is to minimize the number of concepts that you need to deal with in the language. In C# or Java, you only need to understand the object-model (which is fairly complex, though). However, you only have classes with members and instances of classes (objects).

I think this is a very important goal that most of the languages try to follow in one way or another. If C# had some global code (for example to allow interactive evaluation and specification of the startup code without Main method), you'd have one additional concept to learn (top-level code). The choice made by C#/Java is of course just one way to get the simplicity.

Of course, it is a question whether this is the right choice. For example:

  • In functional languages, programs are structured using types (type declarations) and expressions. The body of the program is simply an expression that is evaluated, which is a lot simpler than a class with Main method and it also enables interactive scripting (as in Python).

  • In Erlang (and similar languages), program is structured as concurrently executing processes with one main process that starts other processes. This is a dramatically different approach, but it makes a good sense for some types of applications.

In general, every language has some way of looking at the world and modelling it and uses this point of view when looking at everything. This works well in some scenarios, but I think that none of the models is fully universal. That may be a reason why languages that mix multiple paradigms are quite popular today.

As a side-note, I think that the use of Main method is somewhat arguable choice (probably inheriting from C/C++ languages). I would suppose that more clear object-oriented solution would be to start the program by creating an instance of some Main class.

Tomas Petricek
Good point about the Main convention. Though I remember thinking that in throwaway test code it looked cute to have a class "bootstrap" an instance of itself using a static Main method :)
frou
Nice answer, thank you. I guess I kind of see the point, but I'm not sure it was a good idea to do things the way C#/Java do them. Nevertheless, thanks.
Javier Badia
Steve Yeggie had a great post on the perils of this way of thinking http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html.
Jasmeet
+6  A: 

C# was not designed for "programming in the small". Rather, it was designed for component-oriented programming. That is, for programming scenarios where teams of people are developing interdependent software components that are going to be released in multiple versions over time.

The emphasis on programming-in-the-large and away from programming-in-the-small means that sometimes there is a whole lot of 'ceremony' around small programs. Using this, class that, main blah blah blah, all to write 'hello world'.

The property "a one line program is one line long" would be nice to have in C#. We're considering allowing code outside of classes in small programs as a possible feature in a hypothetical future version of C#; if you have constructive opinions pro or con on such a feature, feel free to send them to me via the contact link on my blog.

Eric Lippert
But why should there be more ceremony for large projects? You would think that it would make things even more complicated.
Javier Badia
@Javier: you want that ceremony for large projects because it (1) enforces discipline, and (2) encourages self-documenting code, and (3) eliminates ambiguities. The cost of the ceremony is paid for in the reduction in bugs.
Eric Lippert
@Eric - I'm not trying to be argumentative, but am legitimately curious: what evidence is there that "the cost of ceremony is paid for in the reduction in bugs"? Do you know of any usability studies along these lines, for instance?
kvb
In my opinion, Code outside a class is like a global variable. If you have a large codebase with dozens of assemblies and hundreds of classes, then not having this ceremony makes things messy IMHO. Sure, with enough discipline that's a non-issue, but in the real world shipping dates are more important than code quality, so having some enforcement of good practices by the language is a good thing. Everything should have a clear place, global code IMHO does not have one.
Michael Stum
A: 

Because having loose function is not Object Orienty enough?

Igor Zevaka