 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / February 2006One 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 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 "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 > "Bart Cremers" wrote... >> I believe it's not possible and I can't see why it should be. A class [quoted text clipped - 16 lines] > > // 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.  Signaturejon martin solaas "Jon Martin Solaas" wrote... >> "Bart Cremers" wrote... >>> I believe it's not possible and I can't see why it should be. [quoted text clipped - 28 lines] > 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 > 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 "P.Hill" wrote... >> Source files are source files, classes are classes. > [quoted text clipped - 3 lines] > 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: [quoted text clipped - 3 lines] > > 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 > 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NotDashEscaped: You need GnuPG to verify this message Oliver Wong schreef: >> 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 [quoted text clipped - 28 lines] > 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. SignatureHendrik Maryns ================== www.lieverleven.be http://aouw.org > 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 >> Just to give an example: >> [quoted text clipped - 3 lines] > 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 >> 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 P.Hill schrieb: >> Just to give an example: >> [quoted text clipped - 5 lines] > > -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; > 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 > Is possible make one class in several files ? No. > I would like do this for organization reason. Strange organisation... -- chris >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. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.