Java:更喜欢实用程序类,具体取决于类实例还是静态方法?

发布于 2024-10-07 01:15:17 字数 1378 浏览 8 评论 0原文

它都会执行类似的操作

public class MyObjectUtil {

    private final MyObject myObject;

    public MyObjectUtil (MyObject myObject){            
        this.myObject = myObject;    
    }

    public boolean isSomeInfoPresentValid() {
        return myObject.isSomething();
    }

    public void modifyMyObjectInSomeWay(String blah) {
        myObject.modify(blah);
    }

}

我有一个 Java 类,每次我必须实例化我的 Utility 类以与 MyObject 的特定实例交互时,

。 myObject 以会话 obj 的形式出现。

MyObjectUtil myObjUtil = new MyObjectUtil(myObject);
myObjUtil.modifyMyObjectInSomeWay("blah");
boolean valid = myObjUtil.isSomeInfoPresentValid();

为了达到相同的结果,我可以使用静态函数,每次使用 myObject 作为方法参数执行相同的操作。

public class MyObjectUtil {

    public static boolean isSomeInfoPresentValid(MyObject myObject) {
        return myObject.isSomething();
    }

    public static void modifyMyObjectInSomeWay(MyObject myObject, String blah) {
        myObject.modify(blah);
    }

}

我不知道该走哪条路。
我在控制器中使用 Util 类,有时我需要针对同一个 myObject 实例调用一些方法,所以对我来说,第一个解决方案似乎更正确。同时,由于我对控制器有很多请求,因此每次都会创建大量 MyObjectUtil 实例,因为 myObject 与特定的 http 请求相关。

我的情况应该走哪条路,而其他情况又应该如何选择?

MyObject 由某些实用程序类以特定方式使用,例如 MyObjectXXXUtil MyObjectYYYUtil。我想在特定的 MyObject 实现之外保留这些 Util 方法(修改 myObject 并检查特定状态),因为它们并不特定于该实现。许多 Util 函数可以以某种方式与 MyObject 交互。

I've a Java class that does something like this

public class MyObjectUtil {

    private final MyObject myObject;

    public MyObjectUtil (MyObject myObject){            
        this.myObject = myObject;    
    }

    public boolean isSomeInfoPresentValid() {
        return myObject.isSomething();
    }

    public void modifyMyObjectInSomeWay(String blah) {
        myObject.modify(blah);
    }

}

Every time I've to instantiate my Utility class to interact with a specific instance of MyObject.

myObject is present as a Session obj

MyObjectUtil myObjUtil = new MyObjectUtil(myObject);
myObjUtil.modifyMyObjectInSomeWay("blah");
boolean valid = myObjUtil.isSomeInfoPresentValid();

To achieve the same result I could have static functions that do the same operations using myObject every time as a method param.

public class MyObjectUtil {

    public static boolean isSomeInfoPresentValid(MyObject myObject) {
        return myObject.isSomething();
    }

    public static void modifyMyObjectInSomeWay(MyObject myObject, String blah) {
        myObject.modify(blah);
    }

}

I don't know which way I should go.
I'm using the Util class in my controllers and sometimes I need to call few methods against the same myObject instance, so to me the 1st solution seems the more correct. At the same time in this way as I've many request against my controllers I can end up creating a lot of MyObjectUtil instances everytime as myObject is related to a specific http request.

Which way should I go in my case and how should I choose in other cases?

MyObject is used in specific ways by some Utilities Classes like MyObjectXXXUtil MyObjectYYYUtil. I would like to mantain these Util methods (that modify myObject and check specific status) out of the specific MyObject implementation, as they are not specific to that. Many Util functions can interact with MyObject in a certain way.

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

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

发布评论

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

评论(2

蝶…霜飞 2024-10-14 01:15:17

如果 MyObjectUtil 中的方法完全依赖于 MyObject 那么我只需将它们放在 MyObject 中即可。当您有很多可以使用这些方法的类时,实用程序类非常有用。

If the methods in MyObjectUtil are completely dependent on MyObject then I would just put them in MyObject. A utility class is useful when you have a lot of classes that can use the methods.

千柳 2024-10-14 01:15:17

以下是之前讨论过此问题的一些其他线程:

Java 实用程序类与服务

Java 抽象类或静态实用程序类设计选择

对我来说,这一切都取决于状态。如果实用程序类不需要状态,那么我会采用静态方法。

此外,您描述的方法可以说存在于对象本身上,作为对该域对象执行的有效操作。

Here are some other threads that have discussed this before:

Java Utility Class vs. Service

and

Java Abstract Class or Static Utility Class Design Choice

For me it all depends on state. If the utility class doesn't need state then I go for the static methodology.

Also the methods you describe could arguably exist on the object itself as valid actions to perform on that domain object.

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