Design for 2 closely related (1 for 1) classes that may alter each other

Question

I have a program that communicates with an API to get information on different organizations, so I have an Organization class and an ApiCall class which are both closely related. As the API I'm using requires different tokens, url endpoints and authentifications to be used depending on the organization I'm trying to get data, I use a different instance of ApiCall for each instance of Organization (basically a 1-1 relationship).

So the first thing that comes to mind is to have an ApiCall instance as a property of Organization, however the api class has several methods that can alter or update data from the Organization class.

So there are many ways of implementing this. Personally I was considering 4 of them:

1. A circular reference, where Organization holds an ApiCall instance as a property and ApiCall holds an Organization instance
2. I could have ApiCall as a nested class inside Organization, however both classes are fairly sizeable (>300 lines) so I don't like the idea of mixing them. So maybe have Organization as a partial class where one file has the Organization methods implementation and the other file has the nested class (ApiCall) implementation?
3. Have a static Dictionary shared across the program correlating the Organization and ApiCall instances
4. Split Organization in 2 classes, OrgData and OrgActions, where OrgActions references ApiCall and OrgData and ApiCall references OrgData

I'm leaning towards alternatives 2 or 4 at the moment, but I was wondering what others would consider the better choice.

Answer 1

First get your responsabilities and names right. It looks to me this is what you have:

OrganizationInfo

This is just a data class, it knows nothing about any API or connection parameters.

ConnectionInfo

This holds parameters to establish the connection with the data source. It knows nothing about an API or organizations.

Connector

This has behavior. It knows how to connect to the data sources, using a ConnectionInfo object. It can on request deliver an OrganizationInfo object for a particular specified organization.

Fetcher

This knows the first three classes and retrieves all organization info records.

You have no circular references.

Answer 2

Your ApiCall should accept an Interface as a parameter.

In other words, you should have an ApiCall method that takes an IOrganization interface with different implementations

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();
    }
}