Use of the "Instance of"

Question

public class AlunoLicenciatura extends Aluno{
    private String curso;
    private ArrayList<Disciplina> l_dis;

    public AlunoLicenciatura(String curso,Aluno a){

        super(a.getNumero(),a.getNome());//recebe o numero e o nome de aluno do objecto do tipo aluno ,neste caso, a1 de acordo com o main
        this.curso=curso;
        this.l_dis=new ArrayList<Disciplina>();
    }
}

public class Aluno {
    private int numero;
    private String nome;


    public Aluno(){
        this.nome="";
        this.numero=0;
    }

    public Aluno(int numero,String nome){
        this.nome=nome;
        this.numero=numero;
    }
}

public class P8 {

    public static int contaAlunosLicenciatura(ArrayList<Aluno> a){
        int c=0;
        for (int i = 0; i < a.size(); i++) {
            if(a.get(i) instanceof AlunoLicenciatura)
                c++;
        }
        return c;
    }

    public static void main(String[] args) {
        Aluno a1 = new Aluno (1, "Gervasio");
        Aluno a3 = new Aluno ();
        Aluno a4 = new Aluno ();
        AlunoLicenciatura al1 = new AlunoLicenciatura("Curso1",a1);
        ArrayList<Aluno> v=new ArrayList<Aluno>();
        v.add(a1);
        v.add(a3);
        v.add(a4);
        int Stlicen=contaAlunosLicenciatura(v);
        System.out.println(Stlicen);

    }
}

I don’t understand why you’re showing up at output 0, if the student a1 was instantiated in the class AlunoLicenciatura al1.

Answer 1

The result is correct since you added a1 who is just a student, no al1 who is a graduate student.

I don’t know if this is a typo (facilitated by bad variable names) or if you thought that the fact that one object receives another object, this other object happens to be something else, which would make no sense.

I actually think this heritage is wrong, which is most clear from the fact that you have to create one parent object and then create another that is a child. The Builder use also seems inadequate.

Answer 2

Assuming that this is a legacy project to which you can’t change the class hierarchy without a major impact, I suggest you apply the Pattern: VISITOR design.

The intention of VISITOR is to allow you to define a new operation for a hierarchy without changing the hierarchy classes. [Steven John Metsker, William C. Wake - 2006, 340 p.]

Seeking to answer: why does function countAlunosLicency is returning 0. Well, I believe it’s because in the hierarchy the parent class doesn’t know their daughter classes, but the sons know which is the father. The daughter class has to behave like the father class:

The Liskov Substitution Principle

New classes must be logical, consistent extensions of their super-classes, but what does it mean to be logical and consistent? A Java compiler will ensure a certain level of consistency, but many consistency principles will elude a compiler. A rule that can help improve your projects is the Liskov Substitution Principle [Liskov, Barbara,1987], which can be paraphrased as follows: An instance of a class must function as an instance of its superclass. [Steven John Metsker, William C. Wake - 2006, 295 p.]

No more theory, now in practice:

public interface AlunoVisitor {
    void visit(AlunoLicenciatura al);
}

Java student.

public class Aluno {
    private int numero;
    private String nome;
    private boolean isAlunoLicenciatura = false;

    public Aluno(){
        this.nome="";
        this.numero=0;
    }

    public Aluno(int numero,String nome){
        this.nome=nome;
        this.numero=numero;
    }

    @Override
    public boolean equals(Object obj) {
        if (obj instanceof Aluno) {
             Aluno aluno = (Aluno)obj;
            if (aluno.numero == this.numero)
                return true;
        }
        return false;
    }

    protected boolean isAlunoLicenciatura() {
        return isAlunoLicenciatura;
    }

    protected void setAlunoLicenciatura(boolean isAlunoLicenciatura) {
        this.isAlunoLicenciatura = isAlunoLicenciatura;
    }

}

Hallucinogenicity.java

public class AlunoLicenciatura extends Aluno
    implements AlunoVisitor {

    private String curso;
    private ArrayList<Disciplina> l_dis;
    
    public AlunoLicenciatura(String curso,Aluno a){
        super(a.getNumero(),a.getNome());//recebe o numero e o nome de aluno do objecto do tipo aluno ,neste caso, a1 de acordo com o main
        this.curso=curso;
        this.l_dis=new ArrayList<Disciplina>();
        this.visitor(a); 
    }

    @Override
    public void visitor(Aluno a) {
        a.setAlunoLicenciatura(true);
    }

}

P8.java

public class P8 {

    public static int contaAlunosLicenciatura(ArrayList<Aluno> a){
        int c=0;
        for (int i = 0; i < a.size(); i++) {
            Aluno aluno = a.get(i);
            if(aluno.isAlunoLicenciatura())
                c++;
        }
        return c;
    }

    public static void main(String[] args) {
        Aluno a1 = new Aluno (1, "Gervasio");
        Aluno a3 = new Aluno ();
        Aluno a4 = new Aluno ();
        AlunoLicenciatura al1 = new AlunoLicenciatura("Curso1",a1);
        ArrayList<Aluno> v=new ArrayList<Aluno>();
        v.add(a1);
        v.add(a3);
        v.add(a4);
        int Stlicen=contaAlunosLicenciatura(v);
        System.out.println(Stlicen);

    }
}

Important to keep in mind the following:

VISITOR is a controversial standard. Some developers avoid consistently applying it, while others advocate its use and suggest ways to strengthen it, although these suggestions generally add complexity. The fact is that many design problems can follow the VISITOR standard. [Steven John Metsker, William C. Wake - 2006, 353 p.]

_{NOTE: The above suggestion is one of many possible. I know you can add complexity, but implementing a Pattern design requires an impact analysis and its cost X benefits. Don’t implement a standard just by implementing.}

_{NOTE 2: Notice I didn’t implement the function: accept(AlunoVisitor al) in class AlunoLicenciatura. This happened because there would be no way to make the class Aluno Abstract. This would imply a very large change in the solution and assuming that we have access restrictions.}

---

Reference:

_{[Steven John Metsker, William C. Wake - 2006], Addison-Wesley Professional; 2 Edition (April 18, 2006), DESIGN PATTERNS IN JAVATM: Software Patterns Series.
[Liskov, Barbara,1987]. Data Abstraction and Hierarchy. SIGPLAN Notices, volume 23, number 5. May 1987.}