Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Is it considered bad form to include a subclass in the same .java file as the superclass? Any inherent advantages or disadvantages of this as opposed to separating them into their own files?
Is it considered bad form to include a subclass in the same .java file as the superclass?
Having the sub class in same .java file that contains a super class is not considered as bad but not recommended. But this opinion varies from person to person so everyone has own opinion.
Any inherent advantages or disadvantages of this as opposed to separating them into their own files?
You know that a single .java file can have only one public class. As from JLS
This restriction implies that there must be at most one such type per
compilation unit. This restriction makes it easy for a Java compiler
to find a named class within a package. In practice, many programmers
choose to put each class or interface type in its own compilation
unit, whether or not it is public or is referred to by code in other
compilation units.
so yes definitely, it can effect the inheritance if you want the sub class to be public as well.
There is no advantage or disadvantage as such.
The main reason behind putting different classes in separate .java files is code organization and maintainability. It is always considered a good practice to put irrelevant classes separately.
For example imagine a scenario when you have a large set of Class and you want to search a particular Class it would be much easier if that Class is written in a separate file rather than incorporating it with other Classes in a same file.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
When programming, there are many indicators that coupling is bad. A class should know as little as possible about other classes. So it is modular and can easily be replaced.
Now, with the introduction of sealed classes, the abstract super-class knows about its sub-classes. As I understand it, the sub-classes would normally be in the same package (or even the same file) as their sealed interface. So there should not be a problem of cyclic dependencies between packages.
So I guess what I am asking is: Should a sealed interface and its sub-classes be regarded as one unit, and not as modular parts that are dependent on each other?
Example where the sub-classes are outside the package:
import asdf.Car;
import asdf.Truck;
public sealed interface Service permits Car, Truck {
To trigger-happy close-voters: An implementor of a sealed interface cannot exist outside the interface's module so the answer is pretty cut and dry. Not opinion-based at all. Here is a comment from Brian Goetz that you might be interested in: Sealed classes for classes in different packages
I already got my answer though so I don't really care if no one else can answer. Have a nice day!
Inheritance is always strong coupling between types; hence most often you should follow
Favor composition over inheritance
Most of the cases when you use inheritance could be resolved with composition and dependency injection.
Keeping subclasses close to the base class inside the one module is a good practice and doing otherwise is not recommended. You don't want to have a strong coupling between not related packages or modules.
There are exceptions to everything I said. F.e You might want to create a library of abstract classes than developers in your project could extend without duplicating utility code. F.ex java collections and abstract collection classes.
.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am beginner and trying to learn by studying material online. I just draw a diagram and want to show you so that you please put me on the right path.
Question-1: Is that drawn correctly
Question-2: How to implement this diagram into Java Code
Trying to build SiteTemplate that has 3 sub classes e.g. (1) different elements like modal, buttons, combo box, table etc (2) Java Script element like error checker and messages (3) all URLs that'll be used in project so that if the site move from one server to another we just change URLs and it start work again
I am trying to that if I inherit SiteTemplate class then have access to all methods of sub classes and their child classes
Best Regards
if I inherit SiteTemplate class then have access to all methods of sub classes and their child classes
No, the fact SiteTemplate is inherited directly or indirectly by other classes does not allow SiteTemplate to have access to the methods of these classes.
In fact this is in the reverse direction, the child classes inherits the public/protected methods of the inherited class(es).
If SiteTemplate correspond to an element of a site your generalizations are right, but what I said above still apply. May be also SiteTemplate is an interface and in this case the generalizations are realizations. In Java you use extends for generalizations and or implements for realizations.
SiteTemplate by default does not know the classes inheriting/realizing it, to make it explicitly knowing them is a bad architecture.
If you want to say a SiteTemplate is composed by any number of ProjectURL and JSElement and HTMLElement the generalizations are wrong and you can use aggregation (or even composition) :
that allows SiteTemplate to access to the elements composing it, and then to apply on these instance the public operations their classes define.
In Java they are attribute, and because the number of instances are unknown you use collections.
Warning, do not name class at plural, so ProjectURL etc whatever these classes have several instances, this is why in my answer I do not use plural
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Following problem: A lot of generated Java classes that look like this:
com.company.project.lib.messages.version1.Message1;
com.company.project.lib.messages.version2.Message1;
com.company.project.lib.messages.version3.Message1;
com.company.project.lib.messages.version4.Message1;
com.company.project.lib.messages.version5.Message1;
...
Each of these Message1 classes has a lot of nested subclasses or constants, e.g.
com.company.project.lib.messages.version1.Message1.VERSION.VERSION_A_WITH_CHANGE_1;
com.company.project.lib.messages.version1.Message1.VERSION.VERSION_B;
com.company.project.lib.messages.version1.Message1.Group1.SubGroupA.Format.MESSAGEFORMAT_1;
com.company.project.lib.messages.version1.Message1.Group1.SubGroupA.Format.MESSAGEFORMAT_2;
...
The nesting becomes even deeper (up to 10 levels).
How do I deal with this? The code quickly becomes unreadable, because comparing to an enum value stretches over multiple lines...
Any ideas?
Java does not have an aliasing system. Therefore, no easy solution exists.
Easy solution: Fix the generator
Whatever is generating this? Fix that. Make that not generate 'Message1' in a million packages, but something more useful, such as 'Message1V1', 'Message1V2', etcetera.
Hard solution: Generate code
Alternatively, if you can't change either the generator code or the template data that the generator uses. You could write a code generator that does something like:
public final class Message1Constants {
public static final Whatever_VERSION_is V1_VERSION =
com.company.project.lib.messages.version1.Message1.VERSION;
}
so that you can write:
import static Message1Constants.*;
...
int x = V1_VERSION.VERSION_B;
You could, of course, manually write this M1Constants class but that does mean you need to remember to update it, and given that the `Message1 classes are generated, you probably don't want that.
Thus, you'd have to ensure this class is, itself, generated.
Writing the generator is quite some effort, and will also complicate your build tooling a little bit. Annotation Processors can be used here (they are, effectively, a 'hook' into the compiler, they run during compilation). A big issue is that compilation runs are incremental, so the annotation processor cannot just 'gather constants' and 'generate a source file' - it needs to analyse the existing source file and leave intact any constants that were generated because of the existence of some input source file that is not part of this incremental run. Even if you know what you are doing this is a multi-day project at the very least.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a class that has many fields made of objects of other classes. This class is used by multiple people who keep adding more fields to it according to their needs. I want to know if there's a drawback to this compared to having one collection field, say a Hashmap, in this class which can be used to contain other classes as and when necessary. This looks cleaner to me than declaring many fields which might end up not being used
A class with too many fields and methods is certainly harder to grasp and change later on - the shorter the class is, the easier it is to understand its uses.
On the other hand, keeping different class variables inside one hashmap in order to make the class shorter is not a good idea at all because you will lose type safety and will have to add many additional checks and castings later on.
In conclusion you should always keep the classes as simple and clean as possible without sacrificing best coding practices - perhaps instead of having so many different fields in one class you could have multiple smaller classes, each with their own responsibility, instead.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
To design a project and draw a UML class diagram, what must the class diagram include?
Suppose our classes have textfields, buttons etc. Must they be included as members?
Suppose we need to perform some form validations, and we intend to perform it by passing data obtained from a form to a "validator" object, must it be also included in the class diagram?
I received some opinions from colleagues that a class diagram is for design phase and must not include objects like I mentioned above. However when the project completes, won't there be a large number of objects we did not draw in the class diagram?
UML is a language. The way you use it is up to you.
Ideally you will have multiple documents. The reason you will need multiple documents is because the most important tip of documentation writing is to restrict yourself to one perspective per document.
You want a static representation of objects -> don't talk about files
You want to show relations between objects -> don't talk about data flow.
You get the idea. As long as you are clear with what the purpose of the document is and consistent to the legend, UML can tell any story.
For your specific question:
Since you're creating a class diagram (a static representation of system objects), the important bits will likely be what goes into each object/class (not the input fields of the form itself, but the structure of the object those fields are eventually saved to), and how they relate to other objects.
You can include the validator object and connect it to the objects its validating, but modeling how it's validating, when it's validating, or the protocol with which they communicate is not relevant for this specific view.
Generally in UML diagrams, you exclude extraneous data. Depending on how in-depth you want to be, things such as a UI controls and getter/setter methods are usually excluded.
On the other hand, your Validator object should be defined as a control class in your UML diagram, as it has a responsibility and purpose within your system.