0

Is there a way in Java to have methods that can be accessed by certain Classes?

class CommonClass{
  void methodAvailableForClassA() {code goes here}
  void methodAvailableForClassB() {code goes here}
}
class A{
  CommonClass cc;
  public void useCC(){
    cc.methodAvalableForClassA();
  }
}
class B{
  CommonClass cc;
  public void useCC(){
    cc.methodAvalableForClassB();
  }
}

What I am asking is if there is a way to make available methods to certain classes

sheilak
  • 5,833
  • 7
  • 34
  • 43
user1840302
  • 189
  • 3
  • 13
  • 1
    Sort of, by arranging your classes in packages carefully. See [this](https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html) for more information on Java access control. – blm Dec 13 '15 at 19:14
  • Not directly but there are many ways to achieve similar results access control, inner classes, interfaces, etc. Depends on what you're trying to accomplish. – pvg Dec 13 '15 at 19:15
  • What i am trying to accomplish is having some CommonClass methods available exclusive to Class A and some methods exclusive to Class B – user1840302 Dec 13 '15 at 20:01
  • 1
    Sounds like a bad design, you should probably have `CommonClass` as an interface or abstract class, and have separate implementations for classes `A` and `B` – Nir Alfasi Dec 13 '15 at 21:43
  • 1
    It's not really clear why you'd want to do this. Could you elaborate? – sisyphus Dec 13 '15 at 23:09

3 Answers3

1

As I wrote in the comments you're not providing enough context and I suspect that this problem can be avoided with a better design.

That said, you can "hack" it by overloading the same method with the different types of the classes, and have the objects send themselves to the method:

class CommonClass{
    void methodAvailableForClass(A a) {...}
    void methodAvailableForClass(B b) {...}
}
class A{
    CommonClass cc;
    public void useCC(){
        cc.methodAvailableForClass(this);
    }
}
class B{
    CommonClass cc;
    public void useCC(){
        cc.methodAvailableForClass(this);
    }
}
Nir Alfasi
  • 53,191
  • 11
  • 86
  • 129
0

This is an X/Y Problem:

You are asking the wrong question, you are asking about a solution that is inappropriate and not the problem.

You should keep methods that are localized to a specific class specialization or implementation of an interface with that implementation.

This is know as High Cohesion and Loose Coupling.

You are trying to do the exact opposite of both of these things, and that is not a good path to be going down.

Any time you have something that is a catch all like CommonClass you are creating a tangled mess of dependencies on completely unrelated things.

Solution:

Those methods that are specialized for each of those classes should be owned by those classes that use them.

Community
  • 1
  • 1
0

As mentioned elsewhere you should be looking for loose coupling - as long as ClassA and ClassB both know about CommonClass you've got strongly coupled code and you've got this kind of problem. However, if you split out separate interfaces which represent the various roles which CommonClass may play then you may be able to pass an instance of CommonClass to each of ClassA and ClassB but as an instance of separate roles which only give the client classes access to specific methods.

e.g.

 public interface RoleForA {
     void methodAvailableForClassA();
 }

 public interface RoleForB {
     void methodAvailableForClassB();
 }

 public class CommonClass implements RoleForA, RoleForB {
    ....
 }

 public class ClassA {
    private final RoleForA cc;
    public void useCC(){
        cc.methodAvailableForClassA();
    }
 }

 public class ClassB{
    private final RoleForB cc;
    public void useCC(){
        cc.methodAvailableForClassB();
    }
 }

The major caveat here is that CommonClass shouldn't just be a dumping ground for all kinds of unrelated functionality. It needs to maintain cohesiveness so you should only do this for the right reason. One example of that might be providing a read-only interface to CommonClass to ClassA and a write-only interface to ClassB. The other thing to be aware of is that the interfaces involved shouldn't be simply tailored to the ClassA/B use cases or else any loose-coupling is purely illusory.

sisyphus
  • 6,174
  • 1
  • 25
  • 35