客户端/服务器 - 服务器可能会发生变化，如何将其抽象出来？
我必须用 Java 实现客户端/服务器架构，其中服务器将来可能会发生变化（嗯，肯定会在某个时候发生变化）。
考虑到这种可能的变化的最佳方法是什么？这是我的想法：
1.）为服务器创建一个接口：
public interface AlarmService {
...
}
2.）创建一个具体的实现：
public AlarmServiceImpl implements AlarmService {
...
}
3.）编写一个静态工厂来获得某种实现
public AlarmServiceFactory {
private AlarmService AlarmServiceFactory() {
return new AlarmServiceImpl();
}
}
这是一个好主意吗？或者这太过分了？或者也许我不应该考虑这种变化？
I have to implement a Client/Server architecture in Java, where the Server may change in the future (well, it definitely will at some point).
What would be the best way to take that possible change into account? Here's what I thought of:
1.) Create an interface for the Server:
public interface AlarmService {
...
}
2.) Create a concrete implementation:
public AlarmServiceImpl implements AlarmService {
...
}
3.) Write a static factory to get some sort of implementation
public AlarmServiceFactory {
private AlarmService AlarmServiceFactory() {
return new AlarmServiceImpl();
}
}
Is this a good idea? Or is this too much? Or maybe I shouldn't take that change into account?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有一句口头禅是“永远针对接口编程，而不是针对实现编程”。虽然在很多情况下都是如此，但很多时候这是矫枉过正的。但就您的情况而言，由于您知道实现会发生变化，并且您对客户端的控制不会像服务器那样多，因此您绝对应该对接口进行编程。
工厂只有在两种情况下才会真正有用。第一个是您有多个可用的实现，您需要决定在运行时生成哪个。另一种情况是，如果您在各处创建新的
AlarmServiceImpl()，并且实现发生变化。否则，我认为使用工厂就太过分了。所以..一定要建立一个接口供客户端/服务器进行通信。仅当交换或选择实现不是一两行代码并且分散在各个地方时才使用工厂。
There is a mantra that goes something along the lines of "always program to an interface, not an implementation". While true in many cases, a lot of time it is overkill. In your case though, since you KNOW the implementation will change, and you won't have as much control over the clients as you do the server, you should definitely program to an interface.
The factory will only really be useful in two cases. The first being that you have several Implementations available, and you need to decide which one to produce at run-time. The other is if you are creating new
AlarmServiceImpl()all over the place, and the implementation changes. Otherwise, I see the use of a factory as overkill.So.. definitely build an interface for the client/server to communicate through. Only use a factory if swapping or choosing implementations isn't one or two lines of code, and is scattered in various places.
考虑业务委托模式。它比已经建议的接口/实现更强大。
Consider Business Delegate pattern. It's more powerful than just interface/implementation suggested already.
这个问题对我来说还不清楚。但我认为你想让你的服务器变得灵活，这样你就可以轻松地改变服务器而不改变其他部分。我说得对吗？如果是的话我认为你应该看看 IOC 模式。
问候
阿里芬。
the question is not cent percent clear to me . but i think that you want to make your server flexible so that you can easily change the server without changing other parts. am i right? if yes then i think you should take a look over IOC pattern.
regards
arefin.