CODEWITHSUNDEEP
java
jax
jax

Reputation: 38583

private interfaces or abstract classes: what are my choices

So here is my problem:

I have used a number of interfaces in my project to help maintain good coding style, however, the design of my software suggests I may be able to export this as a library that I and others can use.

The problem is that of accessibility. In some of my interfaces I do not want others to have access to the methods, but Java enforces them to be public. This is OK in my own projects but I don't want others to be able to access these methods.

For example, I have one interface called Sprite with some of the methods below

Sprite:
void update(Room room);
void draw(Room world, Canvas c);
void updateHealth();
void updateLocation(Room room);
int getLayer();
void shoot();
void setDirection(Direction direction);
...

This is good because all Sprites need these methods but some of them such as draw() I only want my Game Engine to use.

What are my options?

Upvotes: 1

Views: 129

Answers (4)

mmmmmm
mmmmmm

Reputation: 32661

Java allows 4 levels of access private, protected, public and default. (default is with no keyword) Java in a Nutshell calls it default Sun java tutorial also says package-private

default allows access to from classes in the same package.

So in this case make interfaces that only you should access be default so cannot be seen from outside your package.

For Sprite you need to split into 2 interfaces public Sprite containing the ones that external code can use. default for only the Game Engine

The object you make for use by Game Engine can extend both interfaces,

Upvotes: 0

Frank
Frank

Reputation: 10571

What about creating a (or multiple) Facade?

If you have a larger set of classes/interfaces playing together in your library, then a Facade provides a controlled 'interface' to the outside world. More concretely, for your Sprite you can divide your interface into two interfaces: one which is available to the outside world through your Facade, but doesn't include things like draw(). And something like a DrawableSprite for your internal usage. Your internal objects would of course implement both of these interfaces then.

Upvotes: 0

helios
helios

Reputation: 13841

Abstract classes should be fine if:

  • you can have some common implementation (even if it's a very simple one like a couple of properties)
  • you have to define those protected methods
  • and your THINGS are the same kind of objects (is-a relationship). You are saying "all my sprites" so you are saying: "all are sprites of some sub-type".

So... in your case, it seems that an abstract class would fit well.

Don't be afraid. If you need interfaces you can define them later, too (even abstract class implementing an interface with a subset of methods).

Or if you need a change, you can refactor.

Upvotes: 0

pajton
pajton

Reputation: 16226

I would say, narrow the interface of Spirte and move the methods you want to be private to AbstractSprite subclass. This is the easiest way.

Upvotes: 4

Related Questions