public interface UsefulService {
Collection<DataThings> getThings(Identifier id);
}
...以及我们的具体实现：
public class JdbcUsefulServiceImpl implements UsefulService {
//We can break the code for the mapping out into its own class
private Mapper mapper;
@Override
public Collection<DataThings> getThings(Identifier id){
DatabaseQueryResult queryResult = //Code to hit a database and return objects from that domain model
Collection<DataThings> result = mapper.mapFromDatabaseToServiceDomain(queryResult);
return result;
}
}
As Rostislav Matl said, it's useful for when you want to make something that doesn't form part of your package's interface.
As an example, imagine you have a package and it provides an interface and at least one concrete implementation of a service.
People who use this service are going to care about the interface you provide and use one of the concrete classes you provide but they aren't going to care about much else beyond that. Our service has to talk to a database and it needs to be able to map the result from database queries into its own data type (that form its contract).
I find that I regularly create package private helper classes that contain utility type methods or perform tasks like the mapping that we need. Default (package private) visibility is perfect for this because other classes inside your package can use these helpers but no-one outside the package can see them so you're free to change them whenever you like.
This is a an example using some code:
We have our interface:
public interface UsefulService {
Collection<DataThings> getThings(Identifier id);
}
...and our concrete implementation:
public class JdbcUsefulServiceImpl implements UsefulService {
//We can break the code for the mapping out into its own class
private Mapper mapper;
@Override
public Collection<DataThings> getThings(Identifier id){
DatabaseQueryResult queryResult = //Code to hit a database and return objects from that domain model
Collection<DataThings> result = mapper.mapFromDatabaseToServiceDomain(queryResult);
return result;
}
}
Then we have our mapper. We don't need anyone outside the package to care about the service works internally so we use package private visibility and we can have as many classes as we want to get the job done:
class Mapper {
Collection<DataThings> mapFromDatabaseToServiceDomain(DatabaseQueryResult queryResult){
//magic to map objects goes here
}
}
The benefit that we have is that we can always change this Mapper class however we want or delete it or create new package private classes and we know the only (immediate) effects we can cause are inside this package. By immediate effects I mean compiler errors and serious things like that. Obviously you could break your service if you change its behaviour but that's what your automated test suite is there to catch :P
My understaning is package/default access is for package internals, i.e. classes that do not form package interface, i.e. classes that should not be used outside the package.
发布评论
评论（2）
正如 Rostislav Matl 所说，当您想要制作不属于软件包界面一部分的东西时，它非常有用。
举个例子，假设您有一个包，它提供了一个接口和至少一个服务的具体实现。
使用此服务的人将关心您提供的接口并使用您提供的具体类之一，但他们不会关心除此之外的其他内容。我们的服务必须与数据库通信，并且它需要能够将数据库查询的结果映射到它自己的数据类型（形成其契约）。
我发现我经常创建包私有帮助器类，其中包含实用程序类型方法或执行诸如我们需要的映射之类的任务。默认（包私有）可见性非常适合这种情况，因为包内的其他类可以使用这些帮助器，但包外的任何人都无法看到它们，因此您可以随时更改它们。
这是一个使用一些代码的示例：
我们有我们的接口：
...以及我们的具体实现：
然后我们有我们的映射器。我们不需要包外部的任何人来关心服务的内部工作，因此我们使用包私有可见性，并且我们可以拥有尽可能多的类来完成工作：
我们拥有的好处是我们可以随时更改它然而，我们想要或删除它或创建新的包私有类，并且我们知道我们可以引起的唯一（立即）效果是在这个包内。我所说的直接影响是指编译器错误和类似的严重问题。显然，如果您更改服务的行为，您可能会破坏服务，但这就是您的自动化测试套件要捕获的内容：P
As Rostislav Matl said, it's useful for when you want to make something that doesn't form part of your package's interface.
As an example, imagine you have a package and it provides an interface and at least one concrete implementation of a service.
People who use this service are going to care about the interface you provide and use one of the concrete classes you provide but they aren't going to care about much else beyond that. Our service has to talk to a database and it needs to be able to map the result from database queries into its own data type (that form its contract).
I find that I regularly create package private helper classes that contain utility type methods or perform tasks like the mapping that we need. Default (package private) visibility is perfect for this because other classes inside your package can use these helpers but no-one outside the package can see them so you're free to change them whenever you like.
This is a an example using some code:
We have our interface:
...and our concrete implementation:
Then we have our mapper. We don't need anyone outside the package to care about the service works internally so we use package private visibility and we can have as many classes as we want to get the job done:
The benefit that we have is that we can always change this Mapper class however we want or delete it or create new package private classes and we know the only (immediate) effects we can cause are inside this package. By immediate effects I mean compiler errors and serious things like that. Obviously you could break your service if you change its behaviour but that's what your automated test suite is there to catch :P
我的理解是包/默认访问是针对包内部的，即不形成包接口的类，即不应在包外部使用的类。
My understaning is package/default access is for package internals, i.e. classes that do not form package interface, i.e. classes that should not be used outside the package.