Skip to main content

Continuing a class in another .Java file

6 replies [Last post]
Joined: 2007-07-16

After trying to find a solution for this problem online, I found that I couldn't quite phrase my problem just right to retrieve an answer from a search engine. So I thought perhaps asking a hooman would be better.

I have a fairly simple problem. I have a class; class A, which contains all the useful methods and variables for my application. I want to write a series of classes that has direct access to these methods and variables. I solved this by using nested classes.

Now, because of the massive volume of nested classes, I am looking for a way to separate this class into different .java files. As of yet, there is no practical reason for needing to do this; I want to separate the code into other files for no other reason than neatness. It doesn't matter if this implemented at the compile level or at run time, just as long as I can break up my code into convenient .java files.

Thanks in advanced, DJ.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-12-02

neatness would have you restructure your code to get rid of the Godclass syndrome that you're suffering from.
Moving some of those inner classes into toplevel classes is the start, finding the several thousand lines of copy/paste code that are almost certain to be in there and turning them into methods or other classes that are more generic wouldn't hurt either.

Joined: 2003-06-12

If I understand your requirements correctly then following design approach may work better:

1.Add public setters and/or getters based on need basis for each of the private member variable.This will avoid need to access these private fields directly.

2. Categorize internal implementation methods and API to be exposed to outside world by giving appropriate access level to respective methods.

3. Use composition instead of inner classes to build on new functionality around existing functionality.In other words use decorator pattern to add new functionality without touching existing common implementation.
Use abstract factory to get instances of composite classes. Work with interface references instead of actual class objects. This will give layer of abstraction if actual composite class instance is to be replaced with another one.

4. Use singleton pattern if common base state is to be made accessible to added variant /specialized behavior.

5. Keep all classes in same package if you intend to access internal methods of one class in other. But this is not recommended as it compromises encapsulation and data security. Also this restricts the reuse of your classes by other parties as they may not be able to use same package name as of yours.

Joined: 2004-03-18

I have a fairly simple problem. I have a class; class A, which contains all the useful methods and variables for my application. [/i]

It looks very much like these are utility methods. If they don't maintain any state between calls, they can be made static, and if you use static import, then those methods can be "accessed directly" without qualifying them with a class or instance expression.

If some of them do maintain state between calls, then you could move that into a common superclass.

[i]I want to write a series of classes that has direct access to these methods and variables.[/i]

Having dealt with all those methods using these techniques, all the inner classes can become top level classes, extending the common superclass where appropriate, accessing those methods in an unqualified manner.

[i] I solved this by using nested classes.[/i]
bad move.

Joined: 2007-07-17

If your *.java file has grown up only because of the number of inner classes, you should consider to treat these inner classes as "outer" classes, meaning they should live in source files of their own.

It seems to me that your "class" had gained so much functionality that it is more like a "package", so it should treated like one. Furthermore, if it is not just the sheer number of classes but also their size, separating them into independent files would make maintenance much easier.

But the plain answer of your question: it is not possible to spread [i]one single class[/i] over multiple *.java files. This is intentional.

Joined: 2003-06-10

If these nested classes specialize the behavior of Class A then i would say:

you want to use "protected" access for the fields and methods and change these nested classes to extend Class A.

If these nested classes don't necessarily specialize Class A but they form a distinct conceptual group. (Or better yet these classes of objects form a class of an object, that is as a group they are there own state machine which encapsulates there own data) then I would say:

use the default / package access for the common methods and bundle all the classes together in the same package.

If none of these are true then it may be that Class A is a utility. In which case i would see if the members of Class A can be made "static" and therefore accessed directly.

If static classes would not work then the members of Class A could just be made public and these nested classes should be normal classes and
create and instance of Class A as they need it or be passed an instance of Class A in their constructor.

(don't forget to use the import statement)

Joined: 2003-06-12

A solution would be to have the private members declared with package access level and then move the nested classes outside of your huge class. And declare all those classes under the same package.

Like that you could still acess the private members, but they would only be visible inside the package. Think of it like something similar to friend access in C++.