• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Why take code out of Main?

 
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Bartender
Posts: 3225
34
IntelliJ IDE Oracle Spring Chrome Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:
 
Ranch Hand
Posts: 75
  • Likes 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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


 
Ranch Hand
Posts: 79
Eclipse IDE Spring Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Marshal
Posts: 79178
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 79178
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Dotan Cohen
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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).
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 54
MySQL Database PHP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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).
 
Campbell Ritchie
Marshal
Posts: 79178
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 79178
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 79178
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Greenhorn
Posts: 12
Eclipse IDE Flex Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 79178
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Dotan Cohen wrote: . . . And what can one do with this object? . . .

I think somebody has already answered this question.
 
Dotan Cohen
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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!
reply
    Bookmark Topic Watch Topic
  • New Topic