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.
.
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 3 years ago.
Improve this question
I am a C# programmer. Both at my last job and my current one, it is very common to create interfaces for most classes we write. E.g. when we have a class named Spork, we will add an interface ISpork that contains the public methods of Spork.These interfaces are used for dependency injection (e.g. via StructureMap) and for creating mocks in unit tests (e.g. with Rhino Mocks or Moq).
Some weeks ago I attended a talk by a Javs developer. We somehow got to talking about interfaces, and he seemed really surprised that anyone would have lots and lots of one-one-relations between classes and interfaces.
Now my questions: Have I been doing it wrong all the years? Or is this a Java vs C# thing? If it is, how are mocking and dependency injection handled in Java?
P.S.: I am mainly interested in the DI and mocking aspects and the related need (or not?) for lots of interfaces that have only one implementing class. I think the situation re. classes that are neither going to be mocked nor injected is quite similar. But I was surprised that something that seemed like a no-brainer to me as a C# developer was completely unheard of for that Java guy.
DI can be made with classes only without interfaces. You register the type, you inject the type. That's all. The difference comes when talking about mocks in unit tests. In c# you can mock only virtual or abstract (that are also virtual) members. Hence if you want your code to be testable you need to mark all public members with virtual keywords or use an interface instead of real class in your implementation. In Java all methods are virtual by default so they don't have this mess with one-to-one interfaces because they can mock everything.
Dependency injection is used to contain and separate concerns. You want to do something new in your code, you add a dependency interface that does that. You can then test your code without even bothering with the implementation of that interface until later on.
Your question, though, is about one on one relationship between interface and implementation. From my standpoint, that's irrelevant, since you care about the implementation only in the context of the interface you have already declared, not where it is used. You can have a class inheriting multiple injectable interfaces, for example, which is usually a sign that it has too many responsibilities, but it can be done. You can have multiple classes that inherit the same interface and then used based on DI configuration. There are even cases where the DI container handles stuff that I usually relegate to factories, mainly give you the implementation for an interface based on some parameters.
Either way, what does it matter? If (reducing to the absurd) there is one developer per class, then they will only write their code and their tests and define the interfaces of the dependencies needed, letting others implement them.
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.
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 8 years ago.
Improve this question
This question may be a little off-topic but I can't really understand why there is no Interface class in Java.
Every class defined has its java.lang.Class object constructed by JVM. And naturally to me, interfaces should not fall into Class objects, but java.lang.Interface objects instead. That would make sense, wouldn't it?
I know there is this class assignability thing going on so that a class implementing an interface can be casted to that interface, but wouldn't it be a better idea to call it Type instead of Class? And then extend Type to create Class and Interface.
I know for sure Java developers won't do anything about it, but I'm just curious.
You are probably right. Class not only represents classes and interfaces but also enums, arrays and primitive types. Type seems to better describe its purpose. It might also make sense to have derived classes like AnonymousClass. Currently some methods such as getEnclosingConstructor() work only for certain types of classes.
In fact, designers of C# decided to call their equivalent Type.
To know exactly why this was done this way, you would have to ask the people who made that decision. My guess is that in Java 1.0 this made more sense, as Class was more tied to .class file.
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 8 years ago.
Improve this question
Anyone know what the opposite of a Plain Old Java Object is?
I'm talking about your typical terrible java class. Very complicated, tightly coupled, non-modular quagmire of ridiculousness?
Is there a term for a such a class?
Not sure you understand what is meant by POJO, from wiki-pedia a POJO object is simple an object that doesn't:
Extend a prespecified class, implement a prespecified interface or use annotations.
Basically this means an object that isn't part of a broader framework. Most badly designed, tightly coupled java objects are still POJO.
There is no such thing such the "opposite" of the POJO.
POJO is a simple java object (as you correctly say) and is used to separate them from objects which server special causes. I mention some example object categories which are not POJOs:
EJB
java bean
DTO
COM objects
CORBA objects
Hope I helped!
I know "Big Ball of Mud" is a term applied to software architectures that have the characteristics you describe, so maybe you could apply this term to classes as well.
The term POJO is a bit overused. You need to define it clearly so that you can come up with an opposite in your line of thinking. Following could give you an idea.
"POJO describes Java objects or classes that can function on any java context."
Following this description you can probably consider it to be the opposite of Enterprise Java Beans in a Java EE context.
Have a look at Enterprise Java Beans for more information.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
So I have been learning composition and inheritance. Now I understand inheritance is an "is-a" type relationship, and composition is a "has-a" relationship. But does this mean a composition simply refers to a class having an object (or field) of something?
Basically yes, but it has more implications.
The outer object has to protect the enclosed objects from modifications to avoid data corruption. This is usually done through defensive copies creation. If the enclosed objects are immutable this is not necessary
Other implication is to have the enclosing object isolated from the object API so it may change in the future. Let's say the object uses an array and then it decide to use a list instead, by disallowing references to the internal object, the external may change implementation without breaking existing clients.
You may take a look to the chapter: "Prefer composition over inheritance" in the "Effective Java Book" which describes in great these and much other implications.
When you have a situation where a class could extend another class (inheritance), or use another class as a field (composition), go for composition, because it allows you to change the implementation later without affecting any code that uses your class.
When you don't, you forever lock the implementation to be a subclass of the extended class. Any time you do that, it's bad.
An example from the JDK of where inheritance was chosen over composition is the Properties class, which extends Hashtable, when all needed was to use a Hashtable internally and implement a suitable interface. That means you can't substitute in your own implementation of a Properties class, for example with a simple anonymous class.
There are far more examples from the JDK where they got it right, for example HashMap uses a Hashtable, but could easily be changed to use some other hash-based class without affecting its contract or API.
You should always strive to make classes flexible in their implementation.
See Liskov substitution principle