Generische Interfaces mehrfach einbinden

[jCoder1984]

Hallo zusammen

ich habe eine Frage zu generischen Interfaces. Ich möchte Generische Listen als Interface erstellen. Beispiel : Spielerliste, Mannschaftsliste.

Die Listen sollen Opertation zum hinzufügen und entfernen von entsprechenden Objekten (Spieler oder Mannschaft) bereitstellen.

public interface IGenericList<T> {

    /**
     * @return
     */
    public List<T> getElements();

    /**
     * @return
     */
    public T addElementToList(T element);

    /**
     *
     */
    public void removeElementFromList(T element);

}

Allerdings möchte ich in einer Klasse das IGenericList Interface mehrfach anwenden :

public class Competition implements ICompetition, IGenericList<ITeam>, IGenericList<IMember>

Das geht natürlich nicht. Allerdings nun meine Frage wie macht man es besser. Der Grund warum ich gerenische interfaces verwenden will : Solche Listen verwende ich an zeimlich vielen Stellen im Code und möchte natürlich Code Doublizierung vermeinden.

Vielen Dank für eure Anregungen

 

[truesoul]

Hallo.

Also gibt es sicherlich auch eine Liste von Wettbewerben oder?
Im Prinzip IGenericList<ICompetition> irgendwo im Code.

Ich hätte ja gedacht, dass ein Team eine Liste von IGenericList<IMember> hat.
Und Competition eine Liste von IGenericList<ITeam> hat.

Was hast du denn mit der Klasse Competition vor?

Eigentlich brauchst du nur eine Implementierung die die die Wettbewerbe+Team+Member bereitstellt.
Ein Service Team+Member und ein Service Member.

Arbeitest du mit einer Datenbank?

Also Beispiel:

// ITeamService kann natürlich auch sowas sein wie IService<ITeam>
class TeamService implements ITeamService {
    // dependency injection oder new TeamAccess()
    private ITeamAccess teamAccess;

    public IGenericList<ITeam> getAll(){
      
        IGenericList<ITeam> all = teamAccess.findAll();
        return all;
    }
  
    public ITeam getById(long id){
      
        ITeam team = teamAccess.find(id);
        return team;
    }
  
    public boolean addTeam(ITeam team){
        // Team hinzufügen
    }

}
// ITeamAccesskann natürlich auch sowas sein wie IAccess<ITeam>
class TeamAccess implements ITeamAccess {
  
    public IGenericList<ITeam> findAll() {
        // holt die Daten aus der Datei, Datenbank oder anderem und gibt diese Zurück
    }
  
    public ITeam find(long id){
        // holt das Team anhand einer ID und gibt es zurück.
    }
}

Somit musst du eigentlich nicht mehrfach die Listen verwalten. Du initialisiert das Service was du brauchst und verwendest dies.

Grüße

 

[mrBrown]

Allerdings nun meine Frage wie macht man es besser.

In dem Fall vermutlich mit anderem Design

Das ein Wettbewerb eine Liste von Spielern und eine Liste von Mannschaften ist, klingt zumindest etwas komisch.
besser wäre vermutlich, wenn ein Wettbewerb eine Liste von Mannschaften (uU von Spielern) hat.


(Das sieht ja schrecklich aus mit dem 'I' davor >.< )

 

[SchwarzWeiß]

(Das sieht ja schrecklich aus mit dem 'I' davor >.< )

Robert C. Martin rät in seinem Clean Code - Buch auch, es wegzulassen. ("I don’t want my users knowing that I’m handing them an interface.")

 

[mrBrown]

Robert C. Martin rät in seinem Clean Code - Buch auch, es wegzulassen. ("I don’t want my users knowing that I’m handing them an interface.")

Ich bin da ganz seiner Meinung - außerdem macht man sie damit zu irgendwas "besonderem", was sie nicht sein sollten

 

[jCoder1984]

Vielen Dank euch allen für die Antworten.

Ich bin etwas durcheinandergekommen. Ein Competition braucht natürlich keine Member. Aber ein SportsClub hat Member und Teams

Wenn ich das als Service (MemberService und TeamService) implementiere, so kann ich beide ja nicht als Interface vom SportsClub implentieren lassen.

public interface Service<T> {

    /**
     * @return a list with all elements <br>
     */
    public List<T> getAllElements();

    /**
     * @return the new element <br>
     */
    public Optional<T> addElement(T element);

    /**
     * remove an element from the list <br>
     */
    public void removeElement(T element);
}

public interface TeamService extends Service<ITeam>{

}

public interface MemberService extends Service<IMember> {

}

 

[truesoul]

Wenn ich das als Service (MemberService und TeamService) implementiere, so kann ich beide ja nicht als Interface vom SportsClub implentieren lassen.

Na ja, SportClub hat mehrere Teams und Teams hat mehrere Member usw.
Ein Wettbewerb ist zu diesen drei natürlich anders zu sehen.
Aber trotzdem hat ein Wettbewerb mehrere Teams usw.

Du hast im Prinzip:

SportClubService, MemberService, TeamService und Competition.

Und ein Team weiß zu welchem Sport Club es gehört genauso wie Member weiß in welchen Team er spielt usw.

SportClubService beeinhaltet auch ein SportClubAccess und eigentlich erhälst du vom Access die vollständigen Daten. Sprich SportClub mit allen Teams. Pro Team alle Member usw.

Ein Sport Club weiß anhand der Teams wer seine Member sind, wenn wir davon ausgehen, dass wir über Spieler reden. Aber ein Sport Club kann auch ein MemberService beeinhalten, würde nichts dagegen sprechen.

Grüße

 

[mrBrown]

Ich würde da gänzlich auf Service-Terminologie etc verzichten.

Ein Sportclub *hat* Mitglieder und Teams.

Wofür brauchst du an der Stelle dein Interface?

 

[truesoul]

Ich würde da gänzlich auf Service-Terminologie etc verzichten.

Ein Sportclub *hat* Mitglieder und Teams.

Wofür brauchst du an der Stelle dein Interface?

Und warum würdest du darauf verzichten? Direkt vom Controller auf Die Access zugreifen?

 

[mrBrown]

Und warum würdest du darauf verzichten? Direkt vom Controller auf Die Access zugreifen?

Ich sagte *Terminologie*.
Und ja, noch würde ich darauf verzichten (aber auch auf Controller und Access). Erstmal muss doch überhaupt das grundsätzliche Klassen-Design stehen und verstanden sein.

(Btw sollte man dann dazu sagen, was man mit Service meint, je nach Kontext meint das unterschiedliche Dinge.
DDD-Services meint es hier vermutlich nicht?)

 

[truesoul]

Nein. Die Services sollte eher die als Application Service dienen und die Access Implementation wäre so gesehen die Repositories.

Wobei noch nicht beantwortet wurde, ob eine Datenbank im Einsatz ist.

Warum würdest du auf Controller und Access verzichten? Was wäre deine Herangehensweise?

Klassen-Design stehen und verstanden sein.

Kann sein, dass ich ein wenig zu weit ausgeholt habe. Wenn das Klassen-Design noch nicht gut ausgedacht ist, bringt es nicht viel die Anwendungsschichten einzubauen.

 

[mrBrown]

Kann sein, dass ich ein wenig zu weit ausgeholt habe. Wenn das Klassen-Design noch nicht gut ausgedacht ist, bringt es nicht viel die Anwendungsschichten einzubauen.

Eben deshalb würde ich da drauf verzichten, relevant ist erstmal, die Domäne als Klassenstruktur zu repsäsentieren.


Uns zusätzlich ist dann auch noch die Benennung verwirrend, besonders wenn man sie noch so gar nicht kennt, hier gibts ja bei 3 Leuten schon 3 verschiedene Vorstellungen davon...