When I'm using Eclipse i work with lots of Java classes (especially when working with abstract factory design pattern) and I need a way to visually group classes belonging together (different classes extended or implemented from interfaces get mixed together).
I need a way to group classes that extend the same class or implement the same interface so I don't lose my mental health. I started using Eclipse and Java few day ago, so I'm sure I'm missing something to do what i need...
Have you organized your classes in packages? This is precisely what packages are for. If you organize them in packages, you'll have a nice view of the classes belonging together in the Eclipse Package Explorer.
Further reading:
The Java Tutorials: Creating and Using Packages
Import the classes into a UML tool of some kind. There are several free ones out there, including JUDE. Or see if Eclipse has a UML plug-in.
Eclipse has a very handy feature which allows you to see exactly which classes extend (or implement) any class/interface.
Select the superclass/interface/method you are interested in, and press CTRL-T. This will show a popup dialog with the implementing or extending class hierarchy. CTRL-T again will show the super class hierarchy (reverse direction)
You can organize your classes belonging to same event into different packages.for example: com.abc.birds should contain classes related to birds only.com.abc.human should contain all classes related to human only.
Related
My project has currently following package structure.
Here I have added a package name utils and defined all utility classes related to this module inside it. Those have been used by other packages (i.e. impl, internal), and because of that I have made classes and methods in util package public.
Because, it is public, not only classes in this module, classes in other modules can also access this and when I am coding using my IDE they are shown as coding suggestions.
I went through few research papers which describe how this can reduce the usability of the API and give a bad experience to developers who involve in the development [ref1, ref2].
I understand that java does not allow me to make classes inside util accessible to impl and internal packages and not to others.
Is it correct to put my utility classes to a package 'util'? Or should I put all classes that communicate with each other to the same package?
You are correct, something marked public becomes usable in any other package. In contrast to other languages, Java doesn't provide any control beyond that.
A simple workaround: it might be helpful to have one special package containing those public things that should be available to your external users.
Meaning: create something like com.whatever.product.api - and instruct your users that they are fine to use everything from there - but nothing else.
In other words: you make all those things public that you need to public; but you collect those things in a special place that you allow to be used by others.
It is worth mentioning though that Java9 will introduce the concept of modules, those allow you to define which of your packages should be public to users of your module. In that sense, java 9 modules allow you to distinguish between "internal" and "external" public.
Util classes are fine. Util classes are functionality that is used multiple places in a project but doesn't really belong to a specific class.
In a perfect world of OOP there wouldn't be any util classes, but it is however considered a good practice to create util classes if they do not belong to a specific class.
Your options for access modifiers are listed here:
https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html
There is one way to achieve what you you want, it is however concidered a very bad practice. You can change your access modifiers of util classes to protected. This will make your util classes accessible from subclasses and packages. So if a class needs access to one of the util classes, then it has to extend this util class and thereby become a subclass. I cannot stress it enought, this is a very bad practice.
I am new to OOP and java world and trying to understand the concepts.
There are three separate feature projects, each having their own abstract classes and interfaces. I am facing difficulty in wrapping these projects in my test automation solution. I am thinking of using Abstract factory pattern to create features abstract classes and interface in my test automation project. How can i wrap the classes in my project without direct referencing the feature classes.
Thank you in advance for your help.
Sounds like you maybe taking an over complex route..... The solution might be simpler:
Each project should be (at least) in its own package.
Packaging allows java to group classes together under certain namespaces so that their features do not intrude into other classes.
"A package provides a unique namespace for the types it contains.
Classes in the same package can access each other's package-access members."
http://en.wikipedia.org/wiki/Java_package
This question already has answers here:
Are there best practices for (Java) package organization? [closed]
(7 answers)
Closed 8 years ago.
[This is not a duplicate of 23247951]
I'm maybe making too many packages, some are as deep as, for instance, mightypork.gamecore.control.events.input.
Mostly it's nice, but sometimes I'm not sure I'm doing it right. Here's an example image:
Do Tile.java and TileRenderer.java belong into tile package, because they are "top level" abstract or interfaces, or into the subpackages, because the implementations are all there? I want the structure to be logical, but this I'm really unsure about. Note, that this is just an example, I am in similar situation in at least a dozen places.
More generally, is it a good practice to make a subpackage just for concrete implementations of something?
If you define packages try to think about modularity. Which types do address one aspect of your software making up a module with clean boundaries? Which other types define another module which do depend on other modules? Packages in Java seam to be hierarchical but they are not. Never the less, make sub-packages depend on super-packages only and never the other way around. It is ok to have sub-packages which do not depend on super-packages. And do not create technical packages like all my DAOs or all my Controllers. One major driving aspect for a package is the degree of cohesion the types inside the package do have. Another is the layering of your application.
My approach is: start by putting everything into a single package first. When your application evolves, identify the modules and repackage them. Try to keep dependencies between packages low. Check that either types of the same package do depend on each other or they address the same aspect / share related responsibilities.
Well. This is a view, so it might differ from person to person. Yes, its not good to put abstract classes / interfaces and concrete classes in the same package. By looking at you package, anybody should be able to say DoorTile, FloorTile etc all implement / extend Tile. So, they are grouped under the same package. And all abstract classes / interfaces can be grouped under a seperate package.
More generally, is it a good practice to make a subpackage just for concrete implementations of something?
IMO, that decision depends upon how general the interface is ,ie is it possible and very likely that you will write a different implementation of that interface ? If yes - then its better to have a separate package for these various impls - if a single default impl is sufficient then I will just put the interface and Impl together in the same package.
I really wonder that put an Interface and a (Implemented) class in same package or separate is better. I usually put them in same package since I believe it is more convenient to compare.
But couple of days ago, I had an opportunity to use apache GenericObjectPool. Then I found such a package structure like org.apache.commons.pool.impl.
After all, my question is when should I use former one and when should I use the other. Thanks for your sincere answers in advanced:D
One of the tenets of composition is that interfaces are separated from their implementation.
Therefore it doesn't make much sense to constrain interfaces and their implementations to the same package.
(On a system I work on the interfaces are placed in a common area - loosely based on a concept of an interface repository).
If use interfaces just to lower the coupling, you can put interface and implementation into the same package. If you primarily count with more implementations if the interfaces, you should put them in separate package. This really depends on your design and I don't think there is a strict rule. Generally you should design you application as simple as possible and do the refactoring later. So when you start, you can put the implementation into the same package and only when it seems to be needed, you should split it.
If you define the responsibility of a package by its interfaces and classes, you attempt to abstract from concrete implementations. Hence, your package should consist of public types only.
If you continue to provide a default implementation for your package, I do not see any reason why not to put them into the same package. But I would always suggest to put your implementation into a separate project or more specific, to provide the API of your package and the implementation as two different artifacts (for example, jar-files).
Doing things this way, you support the following important aspects of abstraction:
replacement of one implementation with another
ensuring that client code depends only one the API and not the implementation (by adding only the API artifact to the clients classpath)
We implement java.io.Serializable when our class is acting as model class/passing on network and generally we keep all these classes as one package (Say model). Instead of implementing each class, why can't we make a package can be serialize-able?. Anyways we no need to worry about implementations as its a marker interface. I am thinking to make something like "auto-scan in spring".
Edit
com.mycorepackage.model is package where i have all POJO classes which are mapped to ORM (hibernate) and all classes here are java.io.Serializable. I want to make any class from this package is java.io.Serializable without declaring in each class. THINKING out of the box.
There is no way to do this in java since the technical feasibility is questionable.
Where would you write the code that communicates the message 'All classes in this package will implement Serializable'.
What happens when you include other jars that contain the same package but different classes ?
There is one way to implement it at the IDE level. Write a plugin that provides a menu option similar to Right Click -> Source -> Organize Imports on eclipse. That option organizes the imports for all classes under a tree. You can do something similar for classes that are of interest to you. Although I doubt the option would be widely used, it solves your problem.