3

I'm creating a grid based game.

I need to implement a set of obstacles that take random positions within the grid. I've created an abstract class ALifeForm, that holds the common methods for every item within the grid. Obviously, abstract classes can't be initialised, so I was going to create a new class AObstacle, which will extend ALifeForm.

Only issue is, my AObstacle class isn't specialised. All the methods it needs are within ALifeForm.

Can I have an empty class? Is it bad programming practice? And if so, what can I implement instead?

biziclop
  • 48,926
  • 12
  • 77
  • 104
Andrew Willoughby
  • 41
  • 1
  • 1
  • 7
  • 3
    "Can I have an empty Java class?" - Yes. – Maroun Jan 22 '15 at 13:42
  • 2
    What happened when you tried? –  Jan 22 '15 at 13:42
  • 5
    Then why `ALifeForm` is `abstract`, since it's subclasses don't provide anything? – Konstantin Yovkov Jan 22 '15 at 13:43
  • 1
    Have you considered change your class from abstract to concrete? If one subclass can be an exactly copy but with another name, then it may be the case that the superclass should be instantiable. – Bruno Marco Visioli Jan 22 '15 at 13:44
  • 1
    If it fits the way you are modelling the entities in your game, have an empty class. It's fine. – khelwood Jan 22 '15 at 13:44
  • 2
    Instead of an empty `abstract` class, you could consider an `interface` – vikingsteve Jan 22 '15 at 13:44
  • 1
    @BrunoMarcoVisioli: That may work structurally, but I suspect it would cause more problems semantically. That would mean that all child classes are now instances of this concrete base... *thing*. It's likely that this inheritance model isn't the right way to go in the first place. But it's very rare that the solution is to just instantiate the base class. While it may *structurally* work, it introduces weird semantics to the domain. – David Jan 22 '15 at 13:57

2 Answers2

11

Of course...

class AObstacle { }

(Plus whatever inheritance model you're using.) There's nothing stopping you from doing this.

Remember that a class isn't really a thing that you're defining. A type is. The class is just the language/syntax construct used to describe the type. If the type being described has no attributes or operations aside from the inheritance model, then there's nothing else to add to it.

Though you are adding one thing. You're giving it a name. It doesn't sound like much, but defining a semantic concept with a concrete name (particularly in a statically typed environment) is very important. Your type now has an identity apart from other types in the system. If things are added to it later, there's a place to add them without refactorings and breaking changes.

David
  • 208,112
  • 36
  • 198
  • 279
  • 2
    And though empty classes that inherit from an abstract class are probably a code smell, sometimes they are the best way to describe the structures you want to model. Judging by the description of the scenario in the question, this seems to be such a case with one slight caveat: is an obstacle really a life form? Maybe `ALifeForm` should be renamed as `AGridItem` or something similar that encompasses both living things and inanimate obstacles. – biziclop Jan 22 '15 at 13:51
  • @biziclop: Very true. We don't really know enough about the domain being modeled to be certain. This could be a violation of Liskov Substitution as a design consideration, entirely separate from whether or not the language supports empty classes. – David Jan 22 '15 at 13:54
0

Well to do it you don't need to have an abstract class and a class that extends it, or an empty class(wich is possible too).

First way:

You just need to implement two classes: The class that contains the methods and the variables you need to use and the second calss that has an instance of your first class:

public class A{
  public void firstMethod(){
    //do your stuff here
  }
....
}

public class B{
  public static void main(String[] args) {
   A a=new A(); //instantiate your class here 
   a.firstMethod();// then just use its methods
  }
}

Because if you implement a class that extends an abstract class it should implement all its methods.

Second way:

  • Or if you want your second class to be specialized you could have :

your first class wich should not be abstract and the second one can extend it and use all its methods, and have its specific methods

cнŝdk
  • 31,391
  • 7
  • 56
  • 78