为什么要以如此复杂的方式完成?这是OOP的思维方式吗?

发布于 2024-08-23 17:46:03 字数 1711 浏览 11 评论 0原文

我正在尝试使用 Java 中的 Bonjour。我找到了一个如何做到这一点的例子,我想我明白了。但我还是不明白为什么要用这么复杂的方式来做。也许我错过了什么。

所以,我找到的代码< /a> 按以下方式工作(代码也如下所示)。

  1. Java程序尝试查找服务,如果找到服务,程序会尝试“解析”该服务(我认为“解析服务”意味着“使用服务”或“连接到服务” )。

  2. 要“解析”找到的服务,我们需要调用“DNSSD.resolve”方法,并且作为该方法的最后一个参数,我们需要给出一个对象。

  3. “DNSSD.resolve”尝试解析给定的服务。如果“DNSSD.resolve”能够解析服务,它会调用作为最后一个参数给出的实例的“serviceResolved”方法。如果“DNSSD.resolve”无法解析服务,则调用上述对象的“operationFailed”方法。

代码如下:

DNSSD.resolve(0, ifIndex, serviceName, regType, domain, new ResolveListener(){
                public void serviceResolved(DNSSDService resolver, int flags, int ifIndex,
                String fullname, String hostname, int port, TXTRecord txtRecord){
                    InetAddress theAddress;
                    try {
                        theAddress = InetAddress.getByName(hostname);
                    } catch (UnknownHostException e) {
                        // ouch..
                    }
                }

                public void operationFailed(DNSSDService arg0, int arg1) {
                    // ouch, again!
                }
            });

如果按照下面的方式组织代码不是更简单吗?

  1. 我们调用“DNSSD.resolve”方法,其中包含我们要解析的服务的信息。

  2. 我们不会将任何对象传递给“DNSSD.resolve”。

  3. “DNSSD.resolve”不调用任何类的任何方法。

  4. “DNSSD.resolve”尝试“解析”给定的服务,如果能够做到这一点,“DNSSD.resolve”将返回 true。否则返回 false。

  5. 程序根据“DNSSD.resolve”返回的值运行“serviceResolved”或“operationFailed”方法。

    程序根据“DNSSD.resolve”返回的值

或者我只是不习惯OOP的思维方式?

I am trying to use Bonjour from Java. I found an example of how to do it and I think I understood it. But I still do not understand why it should be done in such a complicated way. May be I miss something.

So, the code I found works in the following way (the code is also given bellow).

  1. Java program tries to find a service and if the service is found, the program tries to "resolve" the service (I think "to resolve a service" means "to use a service" or "to connect to a service").

  2. To "resolve" the found service we need to call "DNSSD.resolve" method and as the last argument of this method we need to give an object.

  3. "DNSSD.resolve" tries to resolve a given service. If "DNSSD.resolve" is able to resolve the service it calls "serviceResolved" method of the instance given as the last argument. If "DNSSD.resolve" is unable to resolve the service, ti calls "operationFailed" method of the above mentioned object.

Here is the code:

DNSSD.resolve(0, ifIndex, serviceName, regType, domain, new ResolveListener(){
                public void serviceResolved(DNSSDService resolver, int flags, int ifIndex,
                String fullname, String hostname, int port, TXTRecord txtRecord){
                    InetAddress theAddress;
                    try {
                        theAddress = InetAddress.getByName(hostname);
                    } catch (UnknownHostException e) {
                        // ouch..
                    }
                }

                public void operationFailed(DNSSDService arg0, int arg1) {
                    // ouch, again!
                }
            });

Would it be not simpler to organize the code in the following way.

  1. We call "DNSSD.resolve" method with information about the service we want to resolve.

  2. We do not pass any object to the "DNSSD.resolve".

  3. "DNSSD.resolve" do not call any method of any class.

  4. "DNSSD.resolve" tries to "resolve" a given service and, in the case it was able to do it, "DNSSD.resolve" returns true. Otherwise it returns false.

  5. The program runs either "serviceResolved" or "operationFailed" methods depending on the value returned by the "DNSSD.resolve".

Or I just did not get used to the OOP way of thinking?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

甜尕妞 2024-08-30 17:46:03

与其说是“OOP 思维方式”,不如说是“异步思维方式”。通过对可能需要一段时间的操作使用回调函数,您可以在等待操作完成时去做其他事情(或者只是保持 GUI 响应)。

It's not so much "OOP way of thinking" as "asynchronous way of thinking". By using a callback function on an operation that might take a while, you can go off an do other things (or just keep your GUI responsive) while you're waiting for the operation to complete.

临风闻羌笛 2024-08-30 17:46:03

当然,解决“问题”的方法有很多种。这里采用的方法是回调方法:调用resolve方法并传递给它一个方法(实际上是一个包含方法的对象,因为Java没有匿名方法或闭包等...)。
一旦该解析器(未)成功解析了您希望它解析的任何内容,它将调用您提供给它的 serviceResolved 方法(然后该方法会使用解析器提供的信息执行某些操作)。

这意味着它是一种异步方法,但不是面向对象的。您可以在解析器“工作”时执行其他操作,serviceResolved 方法将在somewhen 被调用,因此您无需等待。

Of course, there are a lot of different ways of approaching a "problem". The approach taken here is a callback approach: You call the resolve method and hand it a method (well, actually an object containing a method, because Java hasn't got anonymous methods or closures etc...).
Once that resolver has (un-)successfully resolved whatever you wanted it to resolve, it will call the serviceResolved method you gave it (which then does something with the information the resolver offers).

That means that it is an asynchronous approach, but not OO. You can do something else while the Resolver is "working", the serviceResolved method will be called somewhen, so you do not need to wait for that.

回忆追雨的时光 2024-08-30 17:46:03

而且该代码是 Java -> JNI-> C代码。没有任何 OO 的东西。它是带有 Java 包装器的异步过程代码。

also that code is Java -> JNI -> C code. There isn't anything OO about it. It is async procedural code with a Java wrapper around it.

濫情▎り 2024-08-30 17:46:03

DNSSD.resolve 的 JavaDoc 指出“大多数操作都是非阻塞的;客户端通过带有操作结果的接口进行回调。回调是从单独的工作线程进行的。”

http://开发人员。 apple.com/mac/library/documentation/Java/Reference/DNSServiceDiscovery_JavaRef/com/apple/dnssd/DNSSD.html

这就是并行性的来源。

The JavaDoc of DNSSD.resolve states that "Most operations are non-blocking; clients are called back through an interface with the result of an operation. Callbacks are made from a separate worker thread."

http://developer.apple.com/mac/library/documentation/Java/Reference/DNSServiceDiscovery_JavaRef/com/apple/dnssd/DNSSD.html

That is where the parallelism comes from.

浅紫色的梦幻 2024-08-30 17:46:03

JBonjourBrowser 中,您可以看到如何其他人引用的“异步方法”用于 JTree 订阅者模型。作者指出,这“特别有帮助……设备通常非常短暂,服务发布后不久就会消失。

In JBonjourBrowser, you can see how the "asynchronous approach", cited by others, is used in a JTree subscriber model. The author's note that this "is especially helpful ... where devices are often very transient and services are announced and disappear shortly afterwards.

梦与时光遇 2024-08-30 17:46:03

回调接口风格常用于异步操作。

在设计接口时,尤其是涉及网络或IO操作的服务时,经常会出现两个问题:
1. 操作是同步(阻塞)还是异步(非阻塞)
2. 操作是否返回值

我们不能说回调风格是否是面向对象的。
面向对象的设计是为每个对象分配明确的职责。

相反,回调机制是面向异步操作的 OO 设计中非常常见的模式。
1.服务负责提供规定的服务
2.回调负责接收服务的响应

The callback interface style is commonly used for asynchronous operation.

When designing an interface, especially services involved in network or IO operation, two questions come up frequently:
1. does the operation synchronous (blocking) or asynchronous (non-blocking)
2. does the operation return a value or not

We cannot say if an callback style is Object Oriented or not.
Object oriented design is about assigning clear responsibility for each object.

In contrary, the callback mechanism is a very common pattern in OO design for asynchronous operation.
1. Service responsible for providing the prescribed service
2. Callback responsible to receiving response of the service

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文