拥有数百种方法的Java对象是否昂贵？

我有一个类似下面的类，包含数百个方法：

public class APIMethods {


public ToView toView;

public APIMethods(ToView toView) {
    this.toView = toView;
}


public static final int SUCCESS = 1;
public static final int ERROR = 0;


public void registerAnonymous(String deviceId, String installRef, final int requestCode) {
    APIInterface apiService =
            RetrofitClientInstance.getRetrofitInstance().create(APIInterface.class);
    JsonObject obj = new JsonObject();
    obj.addProperty("androidId", deviceId);
    obj.addProperty("projectId", 0);
    obj.addProperty("ChannelName", installRef);
    Call<Response<BasicUser>> call = apiService.registerAnonymous("application/json", Utils.getFlavorId(), obj);
    call.enqueue(new Callback<Response<BasicUser>>() {
        @Override
        public void onResponse(Call<Response<BasicUser>> call, Response<Response<BasicUser>> response) {
            Response<BasicUser> mResponse;
            try {
                mResponse = response.body();
                if (mResponse.getErrorCode() == 0)
                    toView.updateView(requestCode, SUCCESS, mResponse);
                else
                    toView.updateView(requestCode, ERROR, mResponse);
            } catch (Exception e) {
                mResponse = new Response<>();
                mResponse.setErrorCode(-1);
                toView.updateView(requestCode, ERROR, mResponse);
                e.printStackTrace();
            }
        }

        @Override
        public void onFailure(Call<PetMarkResponse<BasicUser>> call, Throwable t) {
            Response<BasicUser> numberValidationResponse = new Response<BasicUser>();
            numberValidationResponse.setErrorCode(-1);
            toView.updateView(requestCode, ERROR, numberValidationResponse);
        }
    });
}

///And dozens of such method
}

---

我的问题是这个对象（api）有多贵？请注意，在每个类中，都会调用对象的一些方法。

尝试定义一个内聚类，直到并且除非这些方法与类相关，并且定义了它的用途

下面的链接描述了类中方法的重要性：

---

这件物品一点也不贵

对象包含指向对象类的指针，并且方法与类一起存储。本质上，这些方法都是共享的。一个没有方法的类的对象和一个有10000个方法的类的对象大小相同（假设所有其他方法都相同）

如果有100个字段而不是100个方法，情况会有所不同

---

您可能需要考虑在一个类中使用数百个方法是否是一个好主意。代码是否易于理解和维护？这是“上帝对象”反模式的一个例子吗

这似乎是一个典型的例子。您实际的问题是如何使代码可读，但实际上您是在询问一个包含数百个方法的类是否昂贵

价格昂贵是您最不关心的问题-您应该更担心维护。没有任何理由认为任何类都应该那么大，特别是如果你有很多独立的方法，而每个类只调用其中的几个。这会使课堂很难理解——把它们放在一个地方并不能改善情况

一些评论已经指出了这一点，但你至少应该把它分为几个部分

---

更好的是，将其重构为策略模式，并使用工厂选择使用哪一个。这将满足您的易用性目标，同时避免在一个地方有数百个不相关方法的问题。

如果您需要所有这些方法，您将拥有一个包含大量方法的god（dess）类，或者一组包含较少方法的类。哪一个最有意义完全取决于您的用例。这就是说：一个有“数百个方法”的类很难使用，而且这些方法很可能都是直接相关的。不，这些方法肯定是相互独立的。它们都是api调用，就像我在示例中包含的api调用一样。至少，它们应该按广泛的功能划分，例如，您可能有

user

api调用、

content

api调用等等。很可能还需要进行一些额外的重构。这主意不错。但是性能呢？现在的课程贵吗？这已经被回答了。这个类的问题与可用性相关。是的，代码很容易理解，因为方法是非常独立的。每个方法可以从多个类调用。这就是为什么我把它们集中在一个地方，以便于使用。@Saj我不同意，因为它们是独立的。不相关的代码不应该很接近。更不用说浏览一个有成百上千行的文件了。把它们分成更小的基于主题的类怎么样？比如UserAPI、LoginAPI等？正如戴夫所建议的那样？这并没有解决这个问题，因为这只是一个评论。

APIMethods api = new APIMethods(this);
api.registerAnonymous(Utils.getAndroidId(this), BuildConfig.FLAVOR, STATE_REGISTER_ANONYMOUS);