Is having only one class in a package a code smell?

Is it a bad practice to have a package with only 开发者_如何学运维one class in it? Would it make more sense just to move the single class to a util package that would contain other random useful classes?

Is it a bad practice to have a package with only one class in it?

Not necessarily. It could be a sign of somebody getting obsessed with classifying things. On the other hand, it could just be a logical consequence of a sensible general classification scheme applied in an unusual case.

An example of the latter might be where you have a general API, and multiple implementations of that API, where each of the implementations consists of multiple classes. But one of those implementations (lets call it the Null implementation) consists of just one class.

The real test is whether the package structure is serving its purpose(s):

• Is it making it easier to find library classes?

• Do the packages organize the application classes along the lines of the application's logical module structure?

• Does the structure allow you to effectively make use of "package private" visibility?

Would it make more sense just to move the single class to a util package that would contain other random useful classes?

Not necessarily. If the class is just another "randomly useful" leaf class, then there is a good case for moving it. On the other hand, if it has a specific function and is not intended to be used generally, then it may be better to leave it where it is.

It is best not to get too obsessed with creating elegant package hierarchies, or with rejigging them when they turn out to be not as elegant (or useful) as you first thought. There are usually more important things to do, like implementing functionality, writing tests, writing documentation and so on.

No

Package is used to put similar classes together,
In your system if there is no similar class then obviously you can put it .

Is it a bad practice to have a package with only one class in it?

Not necessarily. Packages are using to group together logically related entities. It doesn't prevent you from having just one such entity in a package.

Would it make more sense just to move the single class to a util package that would contain other random useful classes?

Not to me, for two reasons:

1. Util has a specific meaning. Moving an arbitrary entity to util for reasons of loneliness would be a borderline case of util-abuse.
2. This is premature organization. With Java the IDE support is rich enough to reorganize easily and effectively using a few clicks. Wait a while to see how your project evolves and then take a call.

There are different stategies for static util classes. I use this one :

• if your util class is generic (String utils, DB utils, etc.), I put it in a "util" package, that is used in all the application.
• if the util class is specific to a domain, I call it "DomainHelper" by convention, and put it in the domain package, at the same level as domain classes.

Yes, it's a definite code smell.

This doesn't mean it's necessarily wrong, but there should be a really good reason for a lone class in a package.

Most instances of a package with a single class that I've seen have been erroneous.

Packages should implement features. It's rare that a feature is implemented using only a single class.

Its not 'bad' to have a single class in a package, Create a new package to group more than one related classes and in case if you expect more related classes to your present single logically unrelated class in future to avoid refactoring. Moving all the random utility type classes to a single package is a common practice seen in many places.Its a matter of choice really.

I guess it depends. It is quite rare in to have a package with one class in it because in addition to the answers listed above, packages also serve the purpose of creating a layered system. A package with only one class in it indicates that the decomposition of the system has not surfaced some objects in the system. So, yes, I would take a closer look at this package and question what the purpose is.

It is better not to stick random stuff in an Util package precisely because of the reason mentioned above. You should ask yourself whether you would think to look in Util for your class in the future before putting it there. When Util grows large it starts to get difficult finding the Utility one is looking for.