Mohamed Sanaulla | My Blog | Author of Java 9 Cookbook | Java 11 Cookbook
Oracle Java SE6 Certified Programmer
Oracle Java EE5 Certified Web Component Developer
Pivotal Certified Spring Professional
Certified ScrumMaster
- Rohit
I have thought that for a long time. But it's nice to have a name to put to itNico Van Belle wrote:That's the Single responsibility principle. . . .
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.
Dotan Cohen wrote:However would you not agree that there must be at least one method which coordinates all the others?
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.
Dotan Cohen wrote:
SCJA 6 (Studying for SCJP 6)
the main method isn't a function.Dotan Cohen wrote: . . . benefit of simply banishing the meat of the program from main to another function. . . .
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.Jared Malcolm wrote:[....just instantiate the object and use the constructor for splitting the work from there. . . .
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.
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.
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.
Campbell Ritchie wrote:The benefit is that you get into an object. That is how the language is designed.
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.
I think somebody has already answered this question.Dotan Cohen wrote: . . . And what can one do with this object? . . .
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).
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.
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |