jQuery in Action, 2nd edition*
The moose likes Beginning Java and the fly likes Why take code out of Main? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Why take code out of Main?" Watch "Why take code out of Main?" New topic
Author

Why take code out of Main?

Dotan Cohen
Ranch Hand

Joined: Feb 09, 2011
Posts: 40
I often see Main statements that do nothing more than initiate the current class then call some function in it, like so:


What is this practice called? What advantage it have over simply putting the code in Main:


Thanks!
Mohamed Sanaulla
Saloon Keeper

Joined: Sep 08, 2007
Posts: 3068
    
  33

I dont think this is anything special. But main being a static method- one can access only static fields/methods from the main method. So you might prefer to create an instance of the class and then invoke the method using the instance. For example:


Mohamed Sanaulla | My Blog
Nico Van Brandt
Ranch Hand

Joined: Mar 31, 2011
Posts: 66

That's the Single responsibility principle.

The single responsibility principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.

For me, a Main class is where the program starts executing. Nothing more



Oracle Java SE6 Certified Programmer
Oracle Java EE5 Certified Web Component Developer
Rohit Mehta
Ranch Hand

Joined: Mar 11, 2005
Posts: 79

Also, that is a very general practice - having separate methods for specific functionality & calling them appropriately through main (or others ... as the case).

Think about a large functionality (having lots of lines of code) all implemented directly into main() - it would be a pain to read.


- Rohit
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38492
    
  23
Nico Van Belle wrote:That's the Single responsibility principle. . . .
I have thought that for a long time. But it's nice to have a name to put to it
Dotan Cohen
Ranch Hand

Joined: Feb 09, 2011
Posts: 40
I see. So the idea is that the code _may_ be responsible for more than one duty, and multiple-duty doesn't go in main. So the code is taken out of main even if it is straightforward.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38492
    
  23
No. You write methods which do one thing. In the case of the main method it is starting the application. All your other methods ought to do one thing, too. Single Responsibility. So the code should really be taken out of main full stop.
Dotan Cohen
Ranch Hand

Joined: Feb 09, 2011
Posts: 40
Campbell Ritchie wrote:No. You write methods which do one thing. In the case of the main method it is starting the application. All your other methods ought to do one thing, too. Single Responsibility. So the code should really be taken out of main full stop.


I agree that each method should ideally do only one thing. However would you not agree that there must be at least one method which coordinates all the others? Something like this pseudocode:



Why shouldn't that be in main? I'm not being contentious, rather, I don't understand the tangible benefit of simply banishing the meat of the program from main to another function. I do see that now the running code is in an instance method and not a static method. Other than using more memory, what has that gained us?
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14116
    
  16

Dotan Cohen wrote:However would you not agree that there must be at least one method which coordinates all the others?

Yes, but that doesn't contradict the single responsibility principle. It simply means that the single responsibility that the method has is: coordinate the other methods.

The idea is that you shouldn't write really long methods full of code to do many different things inside that one method.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Dotan Cohen
Ranch Hand

Joined: Feb 09, 2011
Posts: 40
Jesper de Jong wrote:
Dotan Cohen wrote:However would you not agree that there must be at least one method which coordinates all the others?

Yes, but that doesn't contradict the single responsibility principle. It simply means that the single responsibility that the method has is: coordinate the other methods.


And main cannot coordinate the other methods because main's purpose is to start the application? Doesn't the name "main" imply that it does the main body of the work? It's not called start, so where did the idea come from that main should only start another method, and not be the main coordination function?

Again, I'm not being contentious nor am I trying to push a viewpoint. My goal is to be convinced that this common convention, practiced by those far more experienced than myself, is in fact preferable for a technical reason. So far I have not seen any advantage to the convention.

In what other contexts does there exist a function who's only purpose is to call another function, other than the obvious wrapper functions (advantage: compatibility with other code) or doGet wrapping doPost (a specific case of compatibility with other code).
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

main is badly named that is true, but something that "does the main body of the work" is the antithesis to OO design. It's not good practice to have a "do everything" method. This is because such a method is harder to maintain, test, understand, hand over to another developer etc.

Generally, keeping your methods short and classes brief is a good rule of thumb. main is the entry point for your application - once its started your application its job is over.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Jared Malcolm
Ranch Hand

Joined: May 02, 2011
Posts: 54

Dotan Cohen wrote:


You don't really need to have the two lines in main....you can simply call the constructor for the class and then split the work from there.



For me I've always preferred this approach to instantiating the class to a variable name....just instantiate the object and use the constructor for splitting the work from there. I find this way to require minimal extra coding... plus removes concerns about calling a non-static method/variable/whatever.

For the reason(s)....
You shouldn't be making everything static....which is what you'd need to do in order to use main for everything.
It's not how people code on a job (why your learning correct?)
Once you've gotten into using multiple objects/etc this will become more apparent, but the simple answer is that it's how it needs/should be done.

In regards to using more memory....completely 100% pointless comment considering today's hardware. (Not saying that to be rude by any means so please don't take it that way it's just not a valid point to make any longer).


SCJA 6 (Studying for SCJP 6)
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38492
    
  23
Dotan Cohen wrote: . . . benefit of simply banishing the meat of the program from main to another function. . . .
the main method isn't a function.

The benefit is that you get into an object. That is how the language is designed.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38492
    
  23
Jared Malcolm wrote:[....just instantiate the object and use the constructor for splitting the work from there. . . .
The intention of the constructor is to establish the class invariants. Not to execute actions. So the constructor should initialise all uninitialised fields, and that is its single responsibility.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38492
    
  23
In C programming, nearly 40 years ago, the main "function" did actually do the main task of running all the other functions. The main method in Java™ is so called because C and C++ programmers were used to the name "main".
Dotan Cohen
Ranch Hand

Joined: Feb 09, 2011
Posts: 40
Paul Sturrock wrote:main is badly named that is true, but something that "does the main body of the work" is the antithesis to OO design. It's not good practice to have a "do everything" method. This is because such a method is harder to maintain, test, understand, hand over to another developer etc.


That may be true, but simply starting another function from main doesn't make that other function not "do the main body of the work". Looking at the example in the OP, the "do" function does what main would have done, OOo or not. Or maybe you could explain to me how having the code in do instead of main makes the code easier to maintain, test, understand, hand over to another developer etc. Seriously, I _want_ to understand this. I know you're right (on the basis that experienced programmers promote this method), but I am having difficulty seeing the light

Generally, keeping your methods short and classes brief is a good rule of thumb. main is the entry point for your application - once its started your application its job is over.


But the do method is not any shorter than it would have been in main. It would be the exact same code.




Dotan Cohen
Ranch Hand

Joined: Feb 09, 2011
Posts: 40
Jared Malcolm wrote:You don't really need to have the two lines in main....you can simply call the constructor for the class and then split the work from there.[/code]

Thanks, I've never seen it coded that way.

Jared Malcolm wrote:For the reason(s)....
You shouldn't be making everything static....which is what you'd need to do in order to use main for everything.
It's not how people code on a job (why your learning correct?)


Yes, I am studying coding for my day job. Which is quite the reason that I want to understand the practice, not just copy the practice like a monkey. I owe it to my future employer to understand what I'm doing, not to simply copy someone else's style blindly.

Jared Malcolm wrote:Once you've gotten into using multiple objects/etc this will become more apparent, but the simple answer is that it's how it needs/should be done.


I have used multiple objects in classroom exercises, however never more than one object of the class which contains main. Is there a use case where one would make multiple objects of the class which contains main? I do understand that the simple answer is "that it's how it needs/should be done" but exactly the purpose of this thread is to go beyond the simple answer and learn why.

Jared Malcolm wrote:In regards to using more memory....completely 100% pointless comment considering today's hardware. (Not saying that to be rude by any means so please don't take it that way it's just not a valid point to make any longer).


Yes, I understand that the extra few bytes of memory are trivial. I meant to state that the only effect that I see is X (where X is the assignment of more space on the heap), regardless of X is a "positive" or "negative" effect. The point being that I see no other technical effect of the approach.
Dotan Cohen
Ranch Hand

Joined: Feb 09, 2011
Posts: 40
Campbell Ritchie wrote:The benefit is that you get into an object. That is how the language is designed.


And what can one do with this object? Certainly Java programming is not a contest to see who can have the most objects? Certainly there exists a technical benefit to having this object?
Juan Marcos
Greenhorn

Joined: Apr 05, 2011
Posts: 12

Dotan Cohen wrote:
That may be true, but simply starting another function from main doesn't make that other function not "do the main body of the work". Looking at the example in the OP, the "do" function does what main would have done, OOo or not. Or maybe you could explain to me how having the code in do instead of main makes the code easier to maintain, test, understand, hand over to another developer etc. Seriously, I _want_ to understand this. I know you're right (on the basis that experienced programmers promote this method), but I am having difficulty seeing the light

But the do method is not any shorter than it would have been in main. It would be the exact same code.


The example given above was quite general and only written to show a general point, so that may confuse you.

Try looking at your application as a home network, whereas each component is a method that plays a different role.

You may have a TV, cellphone, a few monitors, ps3, speakers, laptop and a desktop. Your router can act as the Main method bringing all the
components together for communication. Now, imagine if you put all of those components into one device (such as a TV). Wrapping up all of
those components into one "TV" wouldn't make things very convenient. What if one component within the TV wasn't working correctly? You would
have to take the whole thing apart to see where the problem is. It may be linked to many other components that rely on it.

What if you needed to use your Main TV as a laptop, then you wouldn't really be able put that Main component on your lap as a portable device, right? What about your stereo system?
What if you wanted to take your Main TV to a friends house? Wouldn't it be easier just to have one component that is portable (metaphor for a class Laptop).

When you begin working with other types of frameworks such as MVC, you may see that breaking code down into classes rather than having one huge Main method
does the job. And usually it may be as simple as plug and play. It would be quite time consuming to maintain and initially even write a program at a bigger scale with just one main class (scary).

Even if it's a small program, writing different methods and classes will offer you something to take with you and use in future projects with little or no changes to the code.

It's not the best analogy, but thinking of different analogies has helped me understand the process.

Spend some time thinking of everything in the world as a possible Java object, write out a class specifying that object in your head,
and see how you could incorporate that object in a Java application. Everyone learns differently, but that may help.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38492
    
  23
Dotan Cohen wrote: . . . And what can one do with this object? . . .
I think somebody has already answered this question.
Dotan Cohen
Ranch Hand

Joined: Feb 09, 2011
Posts: 40
Juan Marcos wrote:When you begin working with other types of frameworks such as MVC, you may see that breaking code down into classes rather than having one huge Main method does the job. And usually it may be as simple as plug and play. It would be quite time consuming to maintain and initially even write a program at a bigger scale with just one main class (scary).


My reply is in reference to the whole post, but specifically the quoted part illustrates my point nicely: I do understand the value of breaking down the code into classes rather than having one huge main method. But that is orthogonal to the concept of putting the code in method doThing() and then simply making an instance of the class and calling doThing(), as many programs do. Although technically the Main method is very short, it appears to me that the advantage of "breaking code down into classes rather than having one huge Main method" is not realized by simple putting all that same code into doThing() and then calling doThing().

Spend some time thinking of everything in the world as a possible Java object, write out a class specifying that object in your head,
and see how you could incorporate that object in a Java application. Everyone learns differently, but that may help.


I did this recently, but I will do it again. It is a good exercise. In fact, I wrote a representation of our city and some neighbors' houses in Java and ran it, just to familiarize myself with the concepts. The purpose of my asking about the issue in this thread is because I am thorough, not lazy!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why take code out of Main?