Two Laptop Bag*
The moose likes Beginning Java and the fly likes implement class methods in header file or normal java file Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "implement class methods in header file or normal java file" Watch "implement class methods in header file or normal java file" New topic
Author

implement class methods in header file or normal java file

Marius Constantin
Ranch Hand

Joined: Nov 23, 2011
Posts: 62

Dear Experts,

Could you please tell me the best practice regarding the proper way to store your methods in a file different than the one who has the main method ?

For exaample

1. file Test.java has

public class Test{

public static void main(String[] args){

a( ); // method A

b( ); // method B

c( ); / method C
}
}

2. Now I want to implement methods a , b and c , in a separate file.

I am thinking

(1) to put this methods in a file called M_Test.java ( methods of class Test), implement them one by one, and call the functions like M_Test.a() in Test.java.

(2) to put them in a file, something like M_Test.h. , C++ like header files, and in Test.java use an import statement, to import the header, and call the methods like a()

Question : it's best practice to use the first or second approach ?

Please advice !

Thank you very much for all your time and help,

Kind regards,

marius

Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39436
    
  28
What’s a header file? Just because C/C++ has them doesn’t mean Java™ has them, too. I made a suggest about C++ earlier: here.

Why are you thinking of class methods at all? You should be thinking of objects and object methods. You create a class which represents the sort of object you plan to create, create an instance, and call the methods on that. If the new class is marked public, it usually must go in a file of its own.
Using class fields and class methods when you do not want them to refer to the class usually suggests you do not understand object-oriented programming.
Marius Constantin
Ranch Hand

Joined: Nov 23, 2011
Posts: 62

Campbell Ritchie wrote:What’s a header file? Just because C/C++ has them doesn’t mean Java™ has them, too. I made a suggest about C++ earlier: here.

Why are you thinking of class methods at all? You should be thinking of objects and object methods. You create a class which represents the sort of object you plan to create, create an instance, and call the methods on that. If the new class is marked public, it usually must go in a file of its own.
Using class fields and class methods when you do not want them to refer to the class usually suggests you do not understand object-oriented programming.



A bit harsh onthe greenhorn, aren't we, without knowing the background of the problem.

Well, this great book that I am reading, and many amazon users who bought this book agree with me, goes through all the building blocks of the Java language, like constants, variables, methods in general, arrays , multidim arrays and maintains a procedural approach towards creating apps in this early stage, for short, until it dives into creating classes , and complicated topics, for a beginner anyway.

So header files do not exist in java ?
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4422
    
    8

Marius Constantin wrote:So header files do not exist in java ?

No, they don't. One file for a class (and usually, but not always, one class for a file).

The real reason header files exist in C/C++ is because compilers want you to have declared a method before you can call it. The Java compiler doesn't have that problem - it's happy for you to call methods that you'll be declaring later.

Edit: C# has the ability to split a class into multiple files, but that's to support automatic code generation - a tool creates one of the files, and you leave that alone and add all your code in another.

As a general rule, if your class has got so big that you want to split it into multiple files, your class is almost certainly too big and should really be decomposed into small, more cohesive classes.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4422
    
    8

Regarding the book - in my opinion the best introductory Java books go straight into the object-oriented stuff, because to get the most out of the language you want to start thinking in that way. E.g. "Thinking in Java" by Bruce Eckel: chapter 1 "Introduction to Objects".
Anayonkar Shivalkar
Bartender

Joined: Dec 08, 2010
Posts: 1509
    
    5

Marius Constantin wrote:Could you please tell me the best practice regarding the proper way to store your methods in a file different than the one who has the main method ?

Well, the best practice would be - put each and every class (except inner classes) in separate file. That way, it is easy to organize the application.
Further, I can see that you are declaring methods a,b and c inside main method - which is quite weird. Java doesn't allow it, but even if it would, I'm just thinking what is use of such approach?

Also, I'm not aware of reasons behind why do you want to declare methods in one file and define (or implement) in another file.

Marius Constantin wrote:Question : it's best practice to use the first or second approach ?

Neither. First approach would give you compile time error, and in second approach, header files are not allowed in Java. There are simply classes and interfaces.

If you haven't written a single Java code yet, and if you are quite comfortable with C++, I would suggest to refer an excellent book named Core Java (Volume I and II). You won't find any better explanation about differences between Java and C++ (and more than that, reasons behind those differences). But if you are new to object oriented concepts, then perhaps Head First Java might be a good start.

Marius Constantin wrote:Well, this great book that I am reading, and many amazon users who bought this book agree with me, goes through all the building blocks of the Java language, like constants, variables, methods in general, arrays , multidim arrays and maintains a procedural approach towards creating apps in this early stage, for short, until it dives into creating classes , and complicated topics, for a beginner anyway.

Which book are you referring to?

Marius Constantin wrote:A bit harsh onthe greenhorn, aren't we, without knowing the background of the problem.

I don't think so. Campbell Ritchie's post contains some really nice suggestions.

Apart from this, I would suggest to stop comparing language specific differences during learning. At each new concept of Java, if you start thinking about its equivalent in C++, you are definitely going to take long time and (unnecessarily) more efforts during learning process.

I hope this helps.


Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
Marius Constantin
Ranch Hand

Joined: Nov 23, 2011
Posts: 62

Matthew Brown wrote:Regarding the book - in my opinion the best introductory Java books go straight into the object-oriented stuff, because to get the most out of the language you want to start thinking in that way. E.g. "Thinking in Java" by Bruce Eckel: chapter 1 "Introduction to Objects".


Thank you very much Matthew for your explanation.

I shall consider this book when I finish with this one.

Kind regards,
marius
Marius Constantin
Ranch Hand

Joined: Nov 23, 2011
Posts: 62

@Anayonkar Shivalkar

This is the book I am currently reading and it's great for a Java beginner with not too much OOP experience.

regarding my best practice question. I have a class with 20 methods that do certain jobs. For the moment I am doing procedural programming inside the main class, if you want to call it this way.
My goal is to easily manage the calls between main method and the 20 methods that do certain jobs in order for the application to display proper output, and the C++ approach of all 20 methods in a file and main methods in another file seemed good to me, since I don't have to go up and down one file 100 times looking for certain lines of code and lose focus.

I wondered if Java had a similar mechanism, since the import java.util.Scanner, for eg, is bringing code to your application.

A bit more clearer now ?

Thank you for your detailed answer and your suggestions.

Kind reagards,
marius
Anayonkar Shivalkar
Bartender

Joined: Dec 08, 2010
Posts: 1509
    
    5

You are welcome.

So, in my opinion, what you need is - redesign.

You can identify 'actors' in your application, create corresponding classes (in different files) and invoke corresponding methods in corresponding objects. e.g. you can have one class to read/write a file which is in specific format, another class which performs a set of critical operations, yet another class which transmits this data over the network and so on.

Further, you can import those classes in your main class file and continue the workflow (like creating corresponding objects, and invoking respective methods etc.)

I hope you got the idea.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39436
    
  28
Marius Constantin wrote: . . . A bit harsh onthe greenhorn, aren't we, without knowing the background of the problem.
Sorry
Well, this great book that I am reading, . . . multidim arrays and maintains a procedural approach . . .
I am surprised; I had thought Liang was a book to recommend. I was obviously mistaken.
It has some poor reviews on Amazon too, but I think those poor reviews were from people who were not themselves very good, and I would disregard them.

I would agree with the recommendations of Eckel’s and Horstmann’s books. I think it’s not a beginner’s book, but from what you have said, I think you are not a beginner.
An import does not bring code to the application. It tells the compiler where to find that other class. This is quite unlike an #include which does insert code from that header into the compiled program. You need to get the notion that everything in radically different from C++ until proven otherwise. I think it was a mistake to make Java™ syntax looik like C++ syntax, because C++ programmers think it means the same thing. They think, for example that int[][] means you have a multi-dimensional array. You haven’t; Java™ doesn’t support multi-dimensional arrays. It supports arrays of arrays, which look similar, but are different (and probably better).
Marius Constantin
Ranch Hand

Joined: Nov 23, 2011
Posts: 62

Anayonkar Shivalkar wrote:You are welcome.

So, in my opinion, what you need is - redesign.

You can identify 'actors' in your application, create corresponding classes (in different files) and invoke corresponding methods in corresponding objects. e.g. you can have one class to read/write a file which is in specific format, another class which performs a set of critical operations, yet another class which transmits this data over the network and so on.

Further, you can import those classes in your main class file and continue the workflow (like creating corresponding objects, and invoking respective methods etc.)

I hope you got the idea.


I got the idea and knew how this works in theory.

And I will too in real life, I just need a minute.

Thank you so much for your help !
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Marius Constantin wrote:I have a class with 20 methods that do certain jobs.


20 public methods? That may be okay, if the methods are short enough and are all related, and it's hard to say for sure without knowing more details of your specific situation, but 20 public methods may be a bit much for one class. Is there any distinction among groups of methods? For instance, to 5 of the methods all only operate on the same parts of the object's state, and not the rest, and nothing else operates on that state? If so, then those 5 methods and that state should go into a different class.

My goal is to easily manage the calls between main method and the 20 methods that do certain jobs in order for the application to display proper output, and the C++ approach of all 20 methods in a file and main methods in another file seemed good to me, since I don't have to go up and down one file 100 times looking for certain lines of code and lose focus.


You certainly can put your main*( method in a separate class, and you probably should. The main() method and the class that contain it should exist solely as an entry point to your app. Your class with 20 methods (or the multiple classes you split it up into) should be totally independent of the main class or whatever is the entry point to your program. They shouldn't know or care if they're running in a standalone app called from your main, or a web app and invoked as part of a servlet's service() method, or an applet, etc.

since the import java.util.Scanner, for eg, is bringing code to your application.


No, it's not. It's just syntactic sugar to tell the compiler that when you write Scanner you mean java.util.Scanner. Imports have precisely zero effect on compiled code.
Larry Chung
Ranch Hand

Joined: Feb 02, 2010
Posts: 247
Probably what could satisfy Marius is to implement his classes and methods by using Inheritance. He could put all the methods in the Parent class and all his child classes simply call on those methods. Could that be what he was trying to articulate?


SCJP 6
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Larry Chung wrote:Probably what could satisfy Marius is to implement his classes and methods by using Inheritance. He could put all the methods in the Parent class and all his child classes simply call on those methods. Could that be what he was trying to articulate?


That doesn't even make any sense, and it would be a horrible thing to do to one's design just to get a file structure that looks more like C++.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39436
    
  28
This is what happens when people come to object-oriented programming (OOP) from a procedural background. They take ages to learn OOP and try to program as they used to in C.
Marius Constantin
Ranch Hand

Joined: Nov 23, 2011
Posts: 62

Campbell Ritchie wrote:This is what happens when people come to object-oriented programming (OOP) from a procedural background. They take ages to learn OOP and try to program as they used to in C.


I think it depends on the Dumb, in your opinion, person, you are referring to, and I also think that this last sentence is way beyond the constructive scope of this forum.

I wonder if this is the right attitude for a Sheriff ? To subtile insult the intelligence of a person.

I personally come to this forum to learn about Java and because people here were always given me constructive advice not insults.

if this happens again,I will be forced to press the magic button.

still kind regards,
marius
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Marius Constantin wrote:
Campbell Ritchie wrote:This is what happens when people come to object-oriented programming (OOP) from a procedural background. They take ages to learn OOP and try to program as they used to in C.


I think it depends on the Dumb, in your opinion, person, you are referring to, and I also think that this last sentence is way beyond the constructive scope of this forum.

I wonder if this is the right attitude for a Sheriff ? To subtile insult the intelligence of a person.

I personally come to this forum to learn about Java and because people here were always given me constructive advice not insults.

if this happens again,I will be forced to press the magic button.

still kind regards,
marius


I'm sure there was no insult intended, and no implication of anyone being "dumb." He merely made an observation that this is a common problem for people making the transition from one kind of programming to another.

It's human nature that it's hard to adjust your thinking and to break a habit. That's all.
 
jQuery in Action, 2nd edition
 
subject: implement class methods in header file or normal java file