Abstract Classes

[Taro]

It's confusing how method classes can be instantiated, trying to figure out where they should be placed within the main method file. To understand abstract classes is one thing, but to extend on them is something that can be very tricky to work with. For example:

public abstract class theem
   {
       public abstract class Power
      {
      
         private Hiker jim;
          public Digit(int vb, int yt)
         {
            jim = new Hiker(vb, yt);
         }
      }

In relation, a non-abstract class must be used in order for an action to be run, for the reason being that the parent is abstract and its children are concrete subclasses?

[Fou-Lu]

I'm not sure exactly what it is you are trying to do here.
Subclassing abstracts that are nested are. . . a pain to say the least. I don't recommend doing it unless you need to. The problem is simply the scope.
Here's an example of that:

PHP Code:

public class theem
{
    public abstract class outer
    {
        public abstract class Power
        {

            public int[] jim;
            public Power(int vb, int yt)
            {
                jim = new int[]{vb, yt};
            }
        }
    }

    class ConcretePower extends outer.Power
    {
        public ConcretePower(outer outer, int vb, int yt)
        {
            outer.super(vb, yt);
        }
    }

    class ConcreteOuter extends outer
    {
    }

    public static void main(String[] argv)
    {
        theem t = new theem();
        outer obj = t.new ConcreteOuter();
        outer.Power p = t.new ConcretePower(obj, 1, 4);
        for (int i : p.jim)
        {
            System.out.println(i);
        }
    }
} 


(I have no idea what these are doing, so I fudged my own compatible datatype for jim).

You'll notice that the nested abstracts are scoped against an instance of object theem (which I promoted to a concrete class and went with the new outer).

Perhaps its better to simply acknowledge the awesomeness that is the interface first which will give a much better understanding of the usefulness of the abstract. Ultimately the purpose here is to create multiple inheritance, where an object of my ConcretePower is both an instance of ConcretePower as well as an instance of theem.outer.Power. Therefore I can operate on it with any method provided in either of the classes.

As for placement in a file, I don't understand the problem. Nothing says you need to nest abstracts. Nesting in Java is already IMO a pain to keep track of everything.

[Taro]

Thanks Mark and Fou-Lou;

I kind of get this abstract stuff I'm learning in Computer Science; in addition, sometimes I had to make sure I was using the right declaration types because I use a file with the main method and a file with a bunch of class methods to refer to.

PHP Code:

class ConcreteOuter extends outer
    {
   
 } 


I was thinking of taking this out of my snippet of code, as I do have an extension of a class in the main method or subclass file. Although it may change the function, I would have to try to actually include an implementation, since that this is not abstract class ConcreteOuter extends outer.

[Fou-Lu]

That one is not supposed to be abstract, it is supposed to be concrete.
You cannot instantiate an abstract class, so in order to demonstrate the extends and nesting I needed to create the two concrete classes. That is very important in order to show the instantiation of the nested classes.

The simplest way to look at the abstract is a skeleton shell. It doesn't know anything other than the absolute basics of what it should be representing. If you have an animal for example ('scuse the example my biology classes are well over a decade behind me so terms are fleeting) you could track the Kingdom, but that's about it. You can then superclass that to another class which may be concrete or abstract which represents the phylum or class, and work down the chain of refinement until you get to the species (which is the bottom so now you need to actually use a concrete). You can implement as many concrete or abstract methods as you want down the chain. Most of these can be implemented to the top level abstract Animalia, so at minimum you'll be able to get the kingdom, phylum, class, uhhh, order? and ultimately down to species. This means you can typecast against the highest abstract (or interface)(perhaps not a great example since you could just as easily use properties):

PHP Code:

public abstract class Animalia
{
    public String getKingdom()
    {
        return "Animalia";
    }
    public abstract Phylum getPhylum();
    public abstract Order getOrder();
    //. . .
}
//. . .
public Phylum getAnimaliaPhylum(Animalia a)
{
    return a.getPhylum();
} 


Since you know you cannot instantiate an Animalia directly, whatever is provided in Animalia for the getAnimaliaPhylum guarantees that you can fetch the .getPhylum on the instance of Animalia a.

One of the best usages of the abstracts is to create the base container for multiple interfaces. Take as many interfaces as you want to implement (but not constantly rewrite) and drop them into an abstract. Refine as needed.