casting an object to an interface benefits

Question

If i have an object with like 50 methods.
And on another class, i needed to store this object and use 2 of these 50 methods.

Does creating an interface with 2 methods and casting the original methods to it saves space?

I mean in this case, will the interface reference contains 50 methods, or will it delete all the methods that are not in the interface and use the needed ones?

The same with abstract classes.

I am a little confused about the refrences, if i used a reference of a small interface with 2 methods to store a class with 50 methods , does that have any benefit .

Here is why i am asking, i see this example in android studio many times:

@Override
    public void onAttach(Context context) {
        super.onAttach(context);

        try {
            CreatedInterface object = (CreatedInterface) context;

        }
        catch (ClassCastException e){
            Log.i(TAG , "on attach failed ");
        }
    }

They never store the entire context refrence, they create an interface with a subset of it.

see this https://stackoverflow.com/questions/21374682/memory-allocation-for-upcasting-in-java — Pavneet_Singh, Aug 30 '17 at 07:46
A size of a reference obviously doesn't change when the referred object has few methods or many. I don't know why you assume that. — Tom, Aug 30 '17 at 07:46

GhostCat · Answer 1 · 2017-08-30T07:54:19.190

This isn't about "saving space". It is about creating a "helpful" OO model.

In that sense: having a class that has 50+ methods is already a severe design smell. Chances are that this class is heavily violating the single responsibility principle for example.

Thus: your idea of now defining an interface that gives a "reduced" view of the class is nothing but an attempt to fix a symptom.

In other words: if you can't change that class - then creating that interface might be a good idea. When other code is only dealing with instances of that interface - you at least prevent your too-big-class design to negatively impact other components in the system. In that sense such an interface can be seen as an "anti corruption layer".

But the real solution would more go like this:

review that 50+ method class
identify the different roles/responsibilities that this class currently implements
split up that one class into the different "parts" - guided by concepts such as the SOLID principles

For the record: there might be situations where 50+ methods are "okay" (think of a typical Swing JComponent that comes with gazillions of methods). But in most cases, 50+ methods is a clear indication of a broken/missing design.

Finally, on the technical aspects: objects do not "carry around" their method implementations. The JVM loads classes into memory once. And an object is basically nothing else but a pointer to a table. And in that table, you find all the methods that this object can invoke. So:

Foo foo = ...
FooInterface  fooInt = (FooInterface) foo

doesn't change anything about foo. There is still one object in memory.

casting an object to an interface benefits

1 Answers1