Design per 2 classi strettamente correlate (1 per 1) che possono alterarsi a vicenda

Question

Design per 2 classi strettamente correlate (1 per 1) che possono alterarsi a vicenda

#1 da (1 voti)
#2 da (-2 voti)

1

Ho un programma che comunica con un'API per ottenere informazioni su diverse organizzazioni, quindi ho una classe Organization e una classe ApiCall che sono entrambe strettamente correlate. Poiché l'API che sto utilizzando richiede token, endpoint e autenticazioni URL da utilizzare a seconda dell'organizzazione che sto cercando di ottenere dati, utilizzo un'istanza diversa di ApiCall per ogni istanza di Organization (in pratica un 1 -1 relazione).

Quindi la prima cosa che viene in mente è di avere un'istanza ApiCall come una proprietà di Organization , tuttavia la classe api ha diversi metodi che possono alterare o aggiornare i dati dalla classe Organization .

Quindi ci sono molti modi per implementarlo. Personalmente stavo considerando 4 di loro:

Un riferimento circolare, dove Organizzazione detiene un'istanza ApiCall come proprietà e ApiCall contiene un'istanza Organization
Potrei avere ApiCall come una classe annidata in Organization , tuttavia entrambe le classi sono abbastanza grandi (> 300 linee), quindi non mi piace l'idea di unirle. Quindi forse Organization come una classe parziale in cui un file ha l'implementazione dei metodi Organization e l'altro file ha l'implementazione della classe nidificata ( ApiCall )?
avere una Dictionary condivisa sul programma correlando le istanze Organization e ApiCall
Dividi Organization in 2 classi, OrgData e OrgActions , dove OrgActions riferimenti ApiCall e OrgData e ApiCall riferimenti OrgData

Al momento mi sto appoggiando alle alternative 2 o 4, ma mi stavo chiedendo quale sarebbe stata la scelta migliore per gli altri.

object-oriented c# object-oriented-design

posta Lucas 11.05.2018 - 20:53

fonte

2 risposte

Leggi altre domande sui tag object-oriented c# object-oriented-design

È più semplice leggere e conservare il codice usando i caratteri "!", o implicando "Not" nel nome del metodo? Possiamo chiamare un'API a pagamento SaaS?

score 1 · Answer 1

Prima acquisisci le tue responsabilità e i tuoi nomi. Mi sembra questo è quello che hai:

OrganizationInfo

Questa è solo una classe dati, non conosce alcun parametro API o connessione.

ConnectionInfo

Questo contiene i parametri per stabilire la connessione con l'origine dati. Non sa nulla di API o organizzazioni.

Connettore

Questo ha un comportamento. Sa come connettersi alle origini dati, usando un oggetto ConnectionInfo. Su richiesta, può fornire un oggetto OrganizationInfo per una particolare organizzazione specificata.

Fetcher

Conosce le prime tre classi e recupera tutti i record di informazioni sull'organizzazione.

Non hai riferimenti circolari.

score -2 · Answer 2

La tua ApiCall dovrebbe accettare un'interfaccia come parametro.

In altre parole, dovresti avere un metodo ApiCall che accetta un'interfaccia IOrganization con diverse implementazioni

public interface IOrganization
{
    void CallOutToServer();
}

public class OrgType1 : IOrganization
{
    public void CallOutToServer()
    {
        // implement the callout logic here
    }
}

public class OrgType2 : IOrganization
{
    public void CallOutToServer()
    {
        // implement the callout logic here
    }
}

public class APiCall
{
    public void DoCallOut(IOrganization org)
    {
        org.CallOutToServer();
    }
}