Associative class with double dependency

Asked

Viewed 201 times

2

I was searching the internet and saw this way of making association between Java classes. Is it correct to make this type of association? 'Cause I did a lot of research on the Internet and I couldn’t find anything similar.

public class Aluno {
    private int codigo;
    private List<AlunoMateria> materias;
}

public class AlunoMateria {
    private Aluno aluno;
    private Materia materia;
    private Time horaAula;
}

public class Materia {
    private int codigo;
    private List<AlunoMateria> alunos;
}
  • What do you want with the Student class? If the Student class had a List<Materia> and the class Materia a List<Aluno> would not be enough?

  • I just wanted to know if this is valid, because in the example we put the time.

2 answers

2


This thing of right or wrong is something that people don’t understand right. There is only right within a context. You didn’t use the word but you’re looking for a good practice, which is a plague because it turns out.

This feels wrong because it makes no sense Aluno have a lot of AlunoMateria (as defined) or a Materia have the same. It seems to mix two concepts. Or you have the class AlunoMateria that makes the tie between the two and would even have a list of them. Or does not have this class and the tie is made with lists in each. I don’t like this because it doesn’t help relationships, has complications to update (viola o DRY data), but I see some people doing it. Then you would have a list of Materias in the Aluno and a list of Alunos in the Materia.

Behold What is the difference between Association, Aggregation and Composition in OOP?. The form I consider ideal is an aggregation, but if you do it the other way is an association.

On the other hand the need may indicate something else.

  • In my case the Alunomateria Table would have other attributes that neither student nor subject would have.

  • One of the reasons I find the best solution but not keep lists of it in the two other objects.

  • You’re talking withdraw private List<Alunomateria> students; I don’t think I understand.

  • Yes, as explained in the reply.

  • Legal worth.

-1

Depends.

In terms of simply implementing, it even makes sense because you will be able to tie this association as expected and necessary in this relationship many-many.

By simply considering object orientation concepts, you could relate classes directly without the need for this "class for association". The fact that it seems little out of reality a student carry the name of the discipline or a discipline carry the name of the student, you even justify the need for this 3rd. entity in your system.

And in this way, the implementation of its AlunoMateria,

IMPORTANT: but recommend, that to meet a better OO presentation and facilitate the readability of your code, the class AlunoMateria might much be called Matricula, becoming much more suited to its purpose and allowing even more legibility OO of its model.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.