So I have to design a DTO in Java, in a way that I have a Profile which has many Roles. This DTO will be served to a front end application. So I create a class named ProfileDTO and a static inner class called Role.
public class Profile {
private List<Role> roles;
// ommiting getters/setters
public static class Role {
}
This way, if I want to create an instance of Role from outside I have to declare it like
var role = new Profile.Role();
I also saw another approach from a colleague of mine though. Have a separate Role class in the same package and just use
private List<Role> roles;
in Profiles class.
So which approach is better? And if it depends, what are the factors it depends on ?
Actually it depends on how you want to represent your domain. In example, if you want the Role class to be accessible to every other class or to have a specific visibility you could create an external class; otherwise, you could use an inner class to have explicitly stated the relation between the Role class and the Profile one.
To cite the tutorial from oracle docs:
Compelling reasons for using nested classes include the following:
It is a way of logically grouping classes that are only used in one place: If a class is useful to only one other class, then it is
logical to embed it in that class and keep the two together. Nesting
such "helper classes" makes their package more streamlined.
It increases encapsulation: Consider two top-level classes, A and B, where B needs access to members of A that would otherwise be
declared private. By hiding class B within class A, A's members can be
declared private and B can access them. In addition, B itself can be
hidden from the outside world.
It can lead to more readable and maintainable code: Nesting small classes within top-level classes places the code closer to where it is
used.
Moreover, regarding the static nested class,
A static nested class is associated with its outer class. And like static class methods, a static nested class cannot refer directly to instance variables or methods defined in its enclosing class: it can use them only through an object reference.
If the inner class is only used by the outer class, I will prefer your approach. It has an object-oriented advantage, an organizational advantage, and a call-back advantage according to https://www.infoworld.com/article/2077411/inner-classes.html . Simply speaking, it means the inner class is logically binded to the outer class so that the inner class can be easily accessed and maintained within the outer class.
However, if the above advantages disappear, inner class will remain code complexity and probably create redundant class for the program.
Related
I have a Java class that is about 4,000 lines long (lots of methods). This class then uses about 200 small classes that only it needs, so another 4,000 lines of code.
If this was C# I would put those other in a partial class file so different file, but they would remain private nested classes only visible to the parent class.
Is there a way to do this in Java? I'm not asking for some methods to be in a distinct file, but for private nested classes to be in a distinct file.
thanks - dave
You can't make a class private to only another class while putting it in a different file.
Use no class access modifier
What you can do is put the classes in separate files with no access modifiers (omit "public"), which will make them package-private, i.e. visible only within its own package. See also the official Access Control tutorial.
UtilClasses.java:
package OurPackage;
class UtilClass1
{
}
class UtilClass2
{
}
MainClass.java:
package OurPackage;
public class MainClass
{
UtilClass1 iAmAUtilClass;
}
Use interfaces or inheritance
You can also achieve something similar with either interfaces or inheritance, by omitting the access modifier from the nested class. This would also be package-private, but this might be preferable to the above in some circumstances, since it avoids having all the nested classes at the top level.
BaseInterface.java:
package OurPackage;
interface BaseInterface
{
class UtilClass1
{
}
}
MainClass.java:
package OurPackage;
public class MainClass implements BaseInterface
{
UtilClass1 iAmAUtilClass;
}
You can also use a base class instead of an interface and extend that with roughly the same effect.
You don't need to implement BaseInterface gain access to its nested classes, but, if you don't, you'd need to use BaseClass.UtilClass1 instead of just UtilClass1.
Inner private classes can't be "extracted" and still be visible only to one particular class. One solution is already mentioned in the comments: Create a package that contains the "main" class and all the previously inner classes and make the inner classes package visible. This would also allow you to create unit tests testing for the correct functionalities of the inner classes, which is something that is most likely currently not happening simply because the inner classes can't be "reached" by a unit test at the moment.
Concepts like declaring "friendships" between classes like in C++ don't exist in Java.
You can replace the inner classes with top-level ones, but you'll have to rewrite a lot of things by hand that the compiler auto-wires for you with the inner-class relationship. To the Virtual Machine, an inner class is nothing special, it's just another class in the same package as the outer class with a fancy name. But the compiler creates a lot of helper constructs under the hood, that you have to reconstruct by hand (or have some refactoring tool do that for you):
The inner class can refer to the outer this instance, by prefixing it with the outer class name. You need to pass the outer this into your inner constructor and store it in a field like outerThis to get access.
In the source code, you can call the outer-class methods directly. You need to rewrite it like outerThis.method(). The same applies to fields.
For private outer methods and fields to become accessible, the compiler creates bridge constructs for you. You have to either change access modifiers or create package-private bridge methods yourself.
In the end, you'll have the former inner classes at least package-visible and being more verbose than the original ones, but on the other hand you'll get better isolation and testability.
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 6 years ago.
Improve this question
I was reading Thinking in Java, about why inner classes exist and what problem they help solve.
The most compelling reason the book tries to give is:
Each inner class can independently inherit from an implementation.
Thus, the inner class is not limited by whether the outer class is
already inheriting from an implementation.
Please help review my understanding:
Inner classes exist since Java doesn't support Multiple Inheritance. This (multiple inheritances) can be done within an Inner class which it is that the Outer class can have multiple inner classes, and each of them can inherit from different classes. So in this way, The multiple inheritances can be implemented. Another reason I can think of is Inner classes address the OOP design principle composition better than inheritance.
Updated
Most of the explanation I found just like the answers below. for example, Inner class used in the GUI framework to deal with the event handler. Not mentioned the reason quoted in the book.I am not saying the answers below are not the good. Actually. I really appreciated them(+1). I just want to know Is there something problem with the book?
It is a little puzzling why you thought of the idea of multiple inheritance after reading the most compelling reason you have quoted from the book. Multiple inheritance comes into question when a class (inner or not) wants to inherit behavior from more than one concrete implementation. Thus, unlike some other languages, in Java, you can not define a class like:
class Child extends Father, Mother {
// Child wants to inherit some behavior from Father and some from Mother
}
As you can see, nothing that only inner classes do can rectify or work around this Java decision (not to support multiple inheritance) in a straightforward way.
Then why do they exist, you may wonder! Well, in Java every class is either top-level or inner (also called nested). Any class that is defined inside another class is an inner class and any class that isn't so is a top-level class.
Naturally, one might wonder why to define classes (i.e. behavior) inside other classes. Aren't top-level classes enough?
The answer is yes. Java could always have only top-level classes. But the idea (perhaps) was there was no good reason to restrict classes from being members of other classes! Just like any predefined type (e.g. Integer, String etc.) can be a member of a class:
class Person {
private String name; // a field the models a Person's name
}
a programmer should be able to define a behavior of one's interest inside the class:
class Person {
private String name; // a field the models a Person's name
private Address address; // address is a type defined here
static class Address {
String street;
String city;
}
}
There's a lot going on here, especially with these things like private, static etc. which are called the modifiers. There are many technical details about them, but let us come back to them later. The essential idea is to be able to define behavior as a part of another class. Could the Address class be defined outside Person class, as a top-level class? Of course. But having this facility comes in handy.
Now, since this facility was introduced, it started serving another purpose and that purpose is called providing code as data. This is how design patterns emerge and it was thought until about 10 years ago that inner classes can be used to provide the data in the form of code. Perhaps this is somewhat puzzling to you. Consider the following code that I have taken almost verbatim from the JDK class: java.lang.String.java:
public static final Comparator<String> CASE_INSENSITIVE_ORDER
= new CaseInsensitiveComparator();
private static class CaseInsensitiveComparator
implements Comparator<String> {
public int compare(String s1, String s2) {
int n1 = s1.length();
int n2 = s2.length();
// details excluded for brevity
// return -1, 0, 1 appropriately
}
}
What has happened here?
We need a way to compare a String to another String and we need to be able to do a case-insensitive comparison. So, we created an implementation of the Comparator interface right inside the outer class: String! Isn't this handy? If inner class wouldn't be there, this would have to be:
public class String {
// ... the whole String class implementation
}
class CaseInsensitiveComparator
implements Comparator<String> {
// implements the comparator method
}
and that's not 'bad' per se, but it means a lot of classes polluting the name space. Inner classes restrict the scope of a behavior to the outer class. That comes in handy, as you'd perhaps see. The data in this case is the implementation of the Comparator interface and the code is well, the same, because we are _new_ing up the inner class we defined.
This feature was exploited further using the anonymous inner classes (especially in the cases where you wanted the code to serve as data) up until Java 7 and they were effectively replaced by Lambda Expressions in Java 8. Nowadays, you might not see any new code that uses anonymous inner classes (in other words, language evolves).
Why Use Nested Classes?
Compelling reasons for using nested classes include the following:
It is a way of logically grouping classes that are only used in one
place: If a class is useful to only one other class, then it is
logical to embed it in that class and keep the two together. Nesting
such "helper classes" makes their package more streamlined.
It increases encapsulation: Consider two top-level classes, A and B,
where B needs access to members of A that would otherwise be declared
private. By hiding class B within class A, A's members can be declared
private and B can access them. In addition, B itself can be hidden
from the outside world.
It can lead to more readable and maintainable code: Nesting small
classes within top-level classes places the code closer to where it is
used.
Oracle Documentation: Understanding inner classes
Below SO question might be interesting to you -
What is the reason for making a nested class static in HashMap or LinkedList?
UPDATE
Not mentioned the reason quoted in the book. ... I just want to know
Is there something problem with the book?
I don't think there is any problem with the statement you have highlighted.
Each inner class can independently inherit from an implementation: That's true right. Just like an outer class, it can inherit from an implementation independently. Just think both of them as separate class.
Thus, the inner class is not limited by whether the outer class is already inheriting from an implementation: As both are separate class, it doesn't matter whether outer class is already inheriting from an implementation. Inner class can inherit from an implementation too. After all it's a class too.
If you are looking for use-cases, I can only tell you what I use them for frequently, which are basically these 2 things:
Static inner classes I use for helping to implement some internal logic. These are usually some form of tuples, or some simple containers. For example: Maps have "Entries" in them which are basically just pairs.
Representing runtime parent-child relationships. These are non-static inner classes. For example: I have a Job class which may instantiate multiple Task inner classes that need to see the data in the job for their processing.
There may be more use-cases of course...
I was reading a code snippet:
Class MyDAO{
public static final MyDAO DAO = new MyDAO();
public void loadData(){
//Hibernate Code to do something
}
...
}
So I'm amazed, and questions I'm facing right now is:
as static keyword denotes that a "member variable, or method, can be accessed without requiring an instantiation of the class to which it belongs". In simple terms, it means that you can call a method, even if you've never created the object to which it belongs.
What is the use of declaring a data member as static and instantiating a class then? is it a design pattern or what? and Most Importantly what is use of that? Any how when you say Class.staticMember how is the class loaded into the memory of JVM?
It can be used to implement Singleton pattern.
Data member is to be declared when you want it to hold same value across all instances(shared between different object of the class)
Declaring static is not a design pattern, but it is a way to design your application.
Further to this if your member is only consumed by methods in class and it is not expected to be accessed directly you can make it private static.
This is a way of providing the DAO object to the rest of the application as a global object. It is crude and ugly and makes testing hard, because it's difficult to provide a mock implementation of the DAO.
Static members are initialized at the time that the class is loaded. Classes are loaded lazily when they are first referenced. Other classes in the application can access this DAO without having to initialize it.
Code like this is why Dependency Injection frameworks (Spring, Guice, Hivemind, etc.) were created. This code makes the application depend on a specific implementation instead of on an abstraction, using dependency injection reduces coupling and increases testability by having the application depend on an abstraction and having the DI container be in charge of selecting the implementation and enforcing singleton scope.
What is the use of declaring a data member as static and instantiating a class then?
Having a data member being static does not give you any reason for not instantiating that class, because your class may still contain other non-static members.
So when do you not have to instantiate the class?
When all your members are static such as a utility class. An example is the Math class in Java.
Most Importantly what is use of that?
If you class contains non-static members, how do you expect those data to be accessed if you do not instantiate the class? Remember that your non-static members will not exist in memory if the class they belongs to is not instantiated.
is it a design pattern or what?
It has no direct relation with design patterns. Generally, you declare a member as static when it is a behaviour or property of the class itself and not individual objects.
Any how when you say Class.staticMember class is loaded into the memory of JVM.
I won't know exactly how Java memory works internally, but static members exist even before object instantiation which means variables declared as static are already created and loaded during runtime.
That also implies static members actually belongs to the class (not individual instance).
I have a question regarding UML. I have a class which simply contains an inner class with the private access modifier - cannot be accessed from anywhere else... Normally in order to present an inner class relation I can use a (+) relation like here (InnerOddIterator):
(taken from http://www.uml-diagrams.org/nested-classifier.html)
I have not found anywhere any information about how can clearly emphasize that this class is private. Do you know if such a method exist at all? If yes I'll be grateful you give me some link here or something?
Just to keep things clear, a sample code:
public class DataStrucure {
// fields, methods, etc
private class InnerOddIterator{
// ...
};
}
From UML point of view. If classifier (Class also) is nested in other class, nesting class plays role of namespace. In this case nested classes are hidden (private) in context namespace. it means, your diagram implicitly defines private inner class definition.
here is part of definition from UML Superstructure section structred classifiers:
"A class acts as the namespace for various kinds of classifiers defined within its scope, including classes. Nesting of
classifiers limits the visibility of the classifier to within the scope of the namespace of the containing class and is used for
reasons of information hiding. Nested classifiers are used like any other classifier in the containing class."
First of all: You have something in your code and asking for an UML representation. But, IMHO, you should look at it the other way round: How can that UML-idea be represented in code. (Some programming languages don't even offer private nested classes...).
As for private nested classes: I suggest using a Composition. It is stronger as Association but not as strong as inheritance. And the composed class can not exist without its composer. Pretty much exactly a private nested class.
The drawing is taken from http://www.uml-diagrams.org/association.html:
In order to indicate that your inner class is privete the best, for me, is to use - character as depicted below but of course in this case you miss the internal structure of your inner class..
What is benefit of using an inner static class? Where should I prefer it over other options?
And how is its memory allocated?
If the inner class is static, you don't need an instance of the outer class to instantiate it.
If the inner class is public, it's basically just a name-scoping technique for highlighting the fact that the class "belongs" to the outer class.
If you make the inner class private however, it can't be used outside of that class.
One of the most compelling reasons for using inner classes is composition. In case of composition the existence of one entity is solely for the purpose of its higher entity. For example a University. A university is composed of Departments. The departments has no individual existence outside the university. Moreover, the access to departments should be controlled by University. In this case, we can have the Department class as an inner class of the University class.
And how is its memory allocated?
The simple answer is that memory for an inner static class is allocated the same way as for a non-nested class. There is nothing special about this case, either with respect to instances of the classes or static members of the class.