One class in several files

java-programmer, One class in several files Hello

Is possible make one class in several files ?
I would like do this for organization reason.

Thanks in advice
GG

java-programmer >> One class in several files I believe it's not possible and I can't see why it should be. A class
is a logical unit to group related functionality. If you want to split
it create multiple classes.

Bart

java-programmer >> One class in several files GG wrote:

> Is possible make one class in several files ?

No.

> I would like do this for organization reason.

Strange organisation...

-- chris

java-programmer >> One class in several files On Tue, 07 Feb 2006 13:23:59 +0100, GG <email***@***.com> wrote, quoted or
indirectly quoted someone who said :

>Is possible make one class in several files ?
>I would like do this for organization reason.

no, unless you use a pre-processor.

I wrote one for Pascal years ago that would either split up into tiny
pieces or glue together. Different task were easier in either form.

Consider splitting off some of your functionality in a helper class.

Sometimes you can use a Decorator class that looks like one big mother
class to the outside world, but inside it delegates is work to an army
of little classes.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

java-programmer >> One class in several files
"Bart Cremers" wrote...
> I believe it's not possible and I can't see why it should be. A class
> is a logical unit to group related functionality. If you want to split
> it create multiple classes.

I can see several valuable uses of the possibility to split the source code
of a class into more than one file, e.g. to be able to separate code from
code generators into one file, and then be able to have a separate file for
"my own" code.

This is what I understand is the main purpose of "partial classes" in C#.

Other possible uses of that possibility could be to separate "interface
implementations" from additional methods, to separate public methods from
private, etc.

My guess is that it *will* be possible in the future, just to stay in the
competition with Microsoft.

// Bjorn A

java-programmer >> One class in several files "GG" <email***@***.com> wrote in message news:dsa37r$187$email***@***.com...
>
> Is possible make one class in several files ?
> I would like do this for organization reason.

Big chance that your class is some sort of "Swiss Army Knife" class, which is a
serious
indication that your design went wrong somewhere.

kind regards,

Jos

java-programmer >> One class in several files Bjorn Abelli wrote:
> "Bart Cremers" wrote...
>> I believe it's not possible and I can't see why it should be. A class
>> is a logical unit to group related functionality. If you want to split
>> it create multiple classes.
>
> I can see several valuable uses of the possibility to split the source code
> of a class into more than one file, e.g. to be able to separate code from
> code generators into one file, and then be able to have a separate file for
> "my own" code.
>
> This is what I understand is the main purpose of "partial classes" in C#.
>
> Other possible uses of that possibility could be to separate "interface
> implementations" from additional methods, to separate public methods from
> private, etc.
>
> My guess is that it *will* be possible in the future, just to stay in the
> competition with Microsoft.
>
> // Bjorn A

I'm sure you have considered using inheritance? Store your code in a
subclass of the generated code? Implement the interface in the
superclass and additional methods in the subclass?

Depending on the application this would either be the right way, or it
might just be letting a file organization issue dictate the whole
application design ... It also sounds like this is kinda workaround for
the lack of multiple inheritance. So before using such a feature I'd be
careful to make sure I wouldn't run into any of the problems being the
reason both C# and Java doesn't have multiple inheritance in the first
place.

--
jon martin solaas

java-programmer >> One class in several files
"Jon Martin Solaas" wrote...
> Bjorn Abelli wrote:
>> "Bart Cremers" wrote...
>>> I believe it's not possible and I can't see why it should be.
>>> A class is a logical unit to group related functionality. If
>>> you want to split it create multiple classes.
>>
>> I can see several valuable uses of the possibility to split the
>> source code of a class into more than one file, e.g. to be able
>> to separate code from code generators into one file, and then be
>> able to have a separate file for "my own" code.
>>
>> This is what I understand is the main purpose of "partial classes" in C#.
>>
>> Other possible uses of that possibility could be to separate
>> "interface implementations" from additional methods, to separate
>> public methods from private, etc.
>>
>> My guess is that it *will* be possible in the future, just to stay
>> in the competition with Microsoft.
>>
>> // Bjorn A
>
> I'm sure you have considered using inheritance? Store your code in a
> subclass of the generated code? Implement the interface in the superclass
> and additional methods in the subclass?
>
> Depending on the application this would either be the right way, or it
> might just be letting a file organization issue dictate the whole
> application design ... It also sounds like this is kinda workaround for
> the lack of multiple inheritance. So before using such a feature I'd be
> careful to make sure I wouldn't run into any of the problems being the
> reason both C# and Java doesn't have multiple inheritance in the first
> place.

I don't say I really need the possibility to split the source files. If I
did, I would already have done so, writing my own preprocessor to merge the
source files before compilation.

Such a possibility would have nothing to do with the lack of multiple
inheritance, as the division of source code wouldn't affect the design of
classes. I rather believe it would be wrong to do the other way around, to
try to achieve the possibility by using multiple classes.

Source files are source files, classes are classes.

I don't see any reason to create additional classes, just because I would
like my view or documentation of the system in a particular way. The design
of the classes should be just that, the *design of classes* based on the
interaction and relations between objects, stemming from a thourough
analysis.

If the possibility to use "partial classes" in Java existed, I probably
would use it, but not as any replacement for OOAD.

// Bjorn A

java-programmer >> One class in several files GG wrote:

> Is possible make one class in several files ?

Kind of - using inheritance.

java-programmer >> One class in several files Bjorn Abelli wrote:
> Source files are source files, classes are classes.

That opinion differs from idea of those who design Java. They
were tired of dealing with mappings between logic and physical.
They made the choice that logical -- the class design --
dictates the physical -- the files on disk. I found it to be a
very useful assumption which avoids all kinds of headaches.

Yet, I could a place for a language support for partial classes
per file as per your comment:

>This is what I understand is the main purpose of "partial classes"
>in C#.

But then I haven't run into a class that I really wanted to break up.

Here is a question. What is the advantage of separate files for
partial classes, other than to avoid any perceived disadvantage to
large source files?

-Paul

java-programmer >> One class in several files
"P.Hill" wrote...
> Bjorn Abelli wrote:
>>
>> Source files are source files, classes are classes.
>
> That opinion differs from idea of those who design Java. They
> were tired of dealing with mappings between logic and physical.
> They made the choice that logical -- the class design --
> dictates the physical -- the files on disk. I found it to be a
> very useful assumption which avoids all kinds of headaches.

Not entirely. It's correct in that the design for a specific class generates
only one .class-file.

But you still have the possibility to have more than one class definition in
a single source file.

So they who designed Java only seem to have "partial problems" with the
mapping... ;-)

> Yet, I could a place for a language support for partial classes
> per file as per your comment:
>
> >This is what I understand is the main purpose of "partial classes"
> >in C#.
>
> But then I haven't run into a class that I really wanted to break up.

Although I never have *needed* it, I've come across situations where I
actually *wanted* to...

> Here is a question. What is the advantage of separate files for
> partial classes, other than to avoid any perceived disadvantage to
> large source files?

Just to give an example:

A couple of years ago, I developed a GUI-builder for Java, to easily
generate "standard" GUI:s, which later on could be "enhanced" by manually
inserting code into the generated code. If the possibility to split the
definition into several files had existed then, I wouldn't have needed to
parse an already generated file, in order to keep the manually inserted code
when regenerating a changed GUI.

// Bjorn A

java-programmer >> One class in several files
"Bjorn Abelli" <email***@***.com> wrote in message
news:email***@***.com...
>
> A couple of years ago, I developed a GUI-builder for Java, to easily
> generate "standard" GUI:s, which later on could be "enhanced" by manually
> inserting code into the generated code. If the possibility to split the
> definition into several files had existed then, I wouldn't have needed to
> parse an already generated file, in order to keep the manually inserted
> code when regenerating a changed GUI.

My solution was to not let the user edit generated files. Instead, the
code generator generates an interface that the user has to implement, in a
class with a specific name. E.g.

<example>
public class GeneratedCode {
public IHumanWrittenCode hwc = new HumanWrittenCode();

public void doA() {
doStuff();
hwc.helpMeWithA();
doMoreStuff();
}
}

public interface IHumanWrittenCode {
public void helpMeWithA();
}
</example>

There'd be a compile error "class not found" on the "new HumanWrittenCode()"
expression. Using Eclipse, the user just needed to right click and choose
"Create class", and the class with the implementing the correct interface,
with the correct filename, in the correct package, would be created, which
the user could then fill out.

- Oliver

java-programmer >> One class in several files -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

Oliver Wong schreef:
>
> "Bjorn Abelli" <email***@***.com> wrote in message
> news:email***@***.com...
>>
>> A couple of years ago, I developed a GUI-builder for Java, to easily
>> generate "standard" GUI:s, which later on could be "enhanced" by
>> manually inserting code into the generated code. If the possibility to
>> split the definition into several files had existed then, I wouldn't
>> have needed to parse an already generated file, in order to keep the
>> manually inserted code when regenerating a changed GUI.
>
> My solution was to not let the user edit generated files. Instead,
> the code generator generates an interface that the user has to
> implement, in a class with a specific name. E.g.
>
> <example>
> public class GeneratedCode {
> public IHumanWrittenCode hwc = new HumanWrittenCode();
>
> public void doA() {
> doStuff();
> hwc.helpMeWithA();
> doMoreStuff();
> }
> }
>
> public interface IHumanWrittenCode {
> public void helpMeWithA();
> }
> </example>
>
> There'd be a compile error "class not found" on the "new
> HumanWrittenCode()" expression. Using Eclipse, the user just needed to
> right click and choose "Create class", and the class with the
> implementing the correct interface, with the correct filename, in the
> correct package, would be created, which the user could then fill out.

Interesting application of the template method pattern.

H.

--
Hendrik Maryns

==================
www.lieverleven.be
http://aouw.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD80dPe+7xMGD3itQRAiWUAJ4mad4dGj52hK3fDsBGg50TEeqJ5QCcDI5Q
4w5Dw1LN9BsFH1Sc+2qU2gU=
=6itv
-----END PGP SIGNATURE-----

java-programmer >> One class in several files Bjorn Abelli wrote:
> Just to give an example:
>
> I wouldn't have needed to
> parse an already generated file, in order to keep the manually inserted code
> when regenerating a changed GUI.

I find subclassing to be a very useful solution in this case,
for example, I have used it to extend hibernate generated classes.

-Paul

java-programmer >> One class in several files
"P.Hill" <email***@***.com> wrote in message
news:dt0q9t$9if$email***@***.com...
> Bjorn Abelli wrote:
>> Just to give an example:
>>
>> I wouldn't have needed to parse an already generated file, in order to
>> keep the manually inserted code when regenerating a changed GUI.
>
> I find subclassing to be a very useful solution in this case,
> for example, I have used it to extend hibernate generated classes.

If the generated code is the one driving the application, it needs to
know the name of your subclass to create an instance of it. Which means (in
this case) you would need to provide parameters giving the name of the
subclass to the code generator. At which case, you might as well just
provide parameters to have it generate the code that couldn't be generated
in the first place.

- Oliver

java-programmer >> One class in several files P.Hill schrieb:
> Bjorn Abelli wrote:
>> Just to give an example:
>>
>> I wouldn't have needed to parse an already generated file, in order to
>> keep the manually inserted code when regenerating a changed GUI.
>
> I find subclassing to be a very useful solution in this case,
> for example, I have used it to extend hibernate generated classes.
>
> -Paul

Extending generated classes is a good aproach.
Especially with hibernate i prefer the opposit direction:
Writing pojos (plain old java objects) and generating the
database-mappings (per xDoclet or [in the newer version] annotations).

With interfaces or extensions most problems can be solved.
Anyways there are three additional possibilities:
1.) reflection/proxy
http://www.dpunkt.de/java/Die_Sprache_Java/Objektorientierte_Programmierung_mit_Java/75.html

2.) bytecode-generation
http://cglib.sourceforge.net/

3.) outsourcing
Source the relevant information out to a config-file and write your
application accordingly general/generic ... (XML is most useful)

Greetings Finomosec;

java-programmer >> One class in several files Oliver Wong wrote:
>> I find subclassing to be a very useful solution in this case,
>> for example, I have used it to extend hibernate generated classes.
>
> If the generated code is the one driving the application, it needs to
> know the name of your subclass to create an instance of it.

The way I was using such a relationship, the class is generated, it is
just the bare bones generated by the tool for O/R mapping (sublcassed
from object but with all the right properties. _I_ subclass and
implement any appropriate additional interfaces special for my use.
Customization goes on top the auto generated class, not the other way
around.

YMMV

-Paul

java-programmer >> One class in several files Finomosec wrote:
> Extending generated classes is a good aproach.
> Especially with hibernate i prefer the opposit direction:
> Writing pojos (plain old java objects) and generating the
> database-mappings (per xDoclet or [in the newer version] annotations).

That works too, then I'd just have to use annotation marking just the
appropriate code, but not being afraid of SQL, I still find I start
with a table create (or a pre-existing DB structure) and then use tools
to generate code to support me in the app.

But I hear ya on using POJOs. That is the way to go.

-Paul