0

Maybe I'm not seeing it, but I can't think of a problem this causes because a static class that extends an abstract class can't be instantiated, but maybe there is a design pattern that I should use instead.

Here is an example of what I'm talking about:

public class PetTrainer
{
    public PetTrainer(...)
    {...}

    public static class LeashInstruction extends LeashInstructionAbstract
    {
    //No Code
    }
}

Within the same package:

abstract class LeashInstructionAbstract
{
    public static void giveTreat(...)
    {...}

    public static...
    //imagine more
}
KeepAtIt
  • 163
  • 12
  • @GhostCat - The nested static class successfully inherits all the abstract class's static methods in my ide, I just checked again to make sure. – KeepAtIt Jun 15 '19 at 15:44
  • @GhostCat - Why are they actively being inherited in IntelliJ then? My intent was to use this to separate and organize the methods away from the nested static class so I'm not looking at 50 methods from 5 different nested static classes everytime I work on the class holding them. Instead, I would be looking at 5 classes seemingly without methods that extend abstract classes hiding their methods. – KeepAtIt Jun 15 '19 at 16:05
  • 2
    Let's step back: you understand that static is considered rather an abnormality in good oop? But you got a point, the methods are inherented. But not in ordinary polymorphism way you might expect. See https://stackoverflow.com/questions/10291949/are-static-methods-inherited-in-java – GhostCat Jun 15 '19 at 16:11
  • 2
    My real concern is: a design that focuses so much on static methods, that simply smells fishy. As said, there is no polymorphism with static methods, and you always directly couple classes when static comes into play. – GhostCat Jun 15 '19 at 16:12
  • I see where you are coming from. I had an inkling that static methods were considered an abnormality in OOP, but I didn't know for sure. Performance comes into play when you have nested classes that are not static, and performance is more important in this use case than keeping to OOP, even though it has a smell. It's highly readable though, which is also a large benefit to this abnormal practice. – KeepAtIt Jun 15 '19 at 16:21
  • 2
    Well, that is all true... As long as you are sure to not run into a situation where static comes back biting you. And are we really talking about hundreds of thousands of calls to your methods? Otherwise I do not buy into your statement that the small overhead when calling non static methods is worth to go with a questionable design... – GhostCat Jun 15 '19 at 16:29

2 Answers2

0

just to clarify the static method is inherited in subclass but it is not polymorphic since you can't override them, though you can hide it when you have a method with the same signature in the subclass. and if you want to make things cleaner you don't need to create an empty static class. Here are my two suggestion based on what you want to achieve. 1. in case that theLeashInstruction is the same for all pet trainers then you can do the following :

public class PetTrainer 
{
    public PetTrainer(...)
    {...}

}

and:

abstract class LeashInstructionAbstract {
    public static void giveTreat() {}
}

  1. in case that the behavior will change among in the PetTrainer class then i would suggest to do the following(interface with abstract methods):

    public class PetTrainer { LeashInstructionImpl leashInstruction = new LeashInstructionImpl(); public PetTrainer() { }

    public static class LeashInstructionImpl implements LeashInstruction {
    @Override
    public void giveTreat() {
        //somthing
    }
}

// Just for testing
public static void main(String[] args) {
    PetTrainer petTrainer = new PetTrainer();
    petTrainer.leashInstruction.giveTreat();
}

    }
    and the LeashInstruction will be:

    interface LeashInstruction { void giveTreat(); //imagine more
    }

Hope That this would help.

Ahmad Shabib
  • 109
  • 5
0

There were many problems with this strategy as I look back on this problem from when I was younger, and attempt to answer it. The first and biggest problem was the load that it put on my ide, copy/pasting all those classes took forever, if I had to do it. The second problem with this strategy as @GhostCat rightly pointed out is that something smelled fishy with the design, it wasn't OOP. If you do this in Java, then you may as well switch to a functional language because it will be much more efficient. This strategy is a mutant of OOP and becomes unmanageable.

KeepAtIt
  • 163
  • 12