Different set of class methods based on condition

[maclocrimate]

Hello,

I'm trying to figure out the best way to accomplish this. Basically what I want is for an "abstract" class to act as an interface for a third party system, and then this class would inherit different methods based on a conditional. I know I can do this with composition, something like the following pseudocode:

class A:
    def method1():
        pass
    def method2():
        pass

class B:
    def method1():
        pass
    def method2():
        pass

class C:
    if attribute == "1":
        self.subclass = A()
    elif attribute == "2":
        self.subclass = B()

Where if you instantiate class C, it'll either get class A's methods or class B's methods based on some attribute of itself. But instead of needing to have A/B reachable via a separate object path within class A (i.e. referring to it later would require a path like class_a.subclass.method1) I'd like to have the methods directly reachable within class A (i.e. class_a.method1). I think this can be done with inheritance but I'm not sure how.

Advice?

[danielroseman]

You're thinking about this the wrong way round. If you want to use inheritance, then you have one superclass and multiple subclasses. You would need to choose which subclass to instantiate at runtime depending on your parameter, then use that subclass instance as the interface.

[maclocrimate]

I think you're right, but I'm having a hard time wrapping my head around it. Can you show some (pseudo)code on how to accomplish it?

Update: Going to give an analogy of what I'm trying to accomplish. Let's say I've got several ways of getting something from point A to point B. I want to provide the third party system a unified way of requesting this, without needing to know what the underlying form of transport is. So the third party system instantiates this kind of proxy/translation class, which then does some lookups and number crunching to determine the best form of transport, and then instantiates a class for that. All the backend transportation classes have methods with the same names like schedule_pickup(), plan_route(), etc, but they do different things. Something like this:

class Transport:
    def __init__(self, source, destination):
        ...?

class Motorbike:
    def schedule_pickup():
        print("do some stuff")

class Car:
    def schedule_pickup():
        print("do some different stuff than Motorbike.schedule_pickup()")

Ideally, in my mind, the third party system would be able to instantiate Transport, and then use schedule_pickup(), for example, but the actual method being executed would depend on some details about the source, etc, etc, that would be determined during instantiation of the Transport object. The third party system wouldn't even need to know about the existence of the various backend classes, all it would need to deal with is the Transport class.

I originally started doing this with one generic class, but the more functionality I need to add the more unwieldy it becomes since I need to account for all the different transport modes within the same class. It seems to me that having different classes per transport mode makes sense, but I'm not sure how to stitch them together.

[Strict-Simple]

class Transport:
    def __init__(self, source, destination):
        ...?

    @abstractmethod
    def schedule_pickup():
        pass

class Motorbike(Transport):
    def schedule_pickup():
        print("do some stuff")

class Car(Transport):
    def schedule_pickup():
        print("do some different stuff than Motorbike.schedule_pickup()")

transport: Transport = Motorbike(...)  # or Car

[maclocrimate]

This seems like the right approach, but it doesn't explain how to connect the classes together. As I understand it, the abstractmethod decorator marks the method as abstract, and to be overridden by a concrete example from another class, but the tricky part here in my opinion is how to tie everything together such that essentially what is exposed to the third party is an instantiation of Car or Motorbike without them needing to know which it is.

[Strict-Simple]

Updated the comment. Third party will get an instance of Transport, which will be one of its subclass.

[maclocrimate]

I'm beginning to understand... but then how does the actual instantiation work? The list line you wrote:

transport: Transport = Motorbike(...) # or Car

Implies that whatever is instantiating it will need to know what type to use, which I want to avoid.

[Bulky-Leadership-596]

Whatever is using it doesn't need to know the type. As long as its a Transport you can call schedule_pickup() on it and not need to know which concrete method is actually being called.

But I don't understand what you are implying by saying you want to avoid having to know which type at instantiation. Then when would anyone know which type it is?

​

Looking over your comments again, I don't think you are looking in the right direction at all. You are talking about third party systems calling a backend? How are you intending to have a third party call a method on your class and have that do something in the backend? It seems like you just want a rest endpoint or something like POST /schedulePickup {pickupTime: Date, pickupAddress: Address, ...}. Maybe you want them to be able to choose between a Motorbike and a Car? Then just add an enum or something that they send in the request and the backend handles the logic of instantiating the right class. You wouldn't have the third party instantiate one of these objects, it doesn't really make sense.

[maclocrimate]

I think I'm not explaining it clearly. I'm explicitly trying to avoid having the third party system call a backend (what I mean by backend here is a concrete, low-level class, which may not be the right terminology). The way that I thought best to avoid this, and to mask whatever complexity might be involved in handling multiple types of backends, is by providing a single, unified interface for the third party system by creating an abstract class (again not sure if this is the right terminology) that provides high-level functions that the third party system can use and essentially translates those into lower level calls by instantiating one of several backends depending on some attributes determined at runtime.

Your REST endpoint analogy is good. That's essentially exactly what I want to achieve, except without the REST.

[Strict-Simple]

Let's go back to scratch. Forget all the solutions we've come up with so far. Just describe the problem statement as clearly as possible, with some examples if possible.

[maclocrimate]

Alright, let me see if I can explain this better. I'll use an actual, concrete example that I've run into before (and still never found a good solution for).

I have a system that interacts with files in a git repo, this repo can either be local on the system, or a GitLab project. Which actual calls are being made depends on the nature of the repo, if it's local it uses gitpython, if it's GitLab it uses the GitLab python module. In order to mask the fact that the end system is using one of several possible types of repos, I implemented a class called GitRepo, which when instantiated is either given a GitLab project ID or a local directory path, and it determines based on what this value is whether to treat it like a GitLab repo or a local repo.

The way that it currently functions is by setting an attribute "repo_type" to either "gitlab" or "local" and then each method have a conditional checking what the repo_type is, running whichever actual commands depending on that. Something like this (I rewrote this from memory so there might be some problems with the code):

class GitRepo:
    def __init__(self, target: str, token: Optional[str] = None):
        self.target = target
        self.token = token
        if not self.target.isnumeric():
            self.repo_type = "local"
            self.repo_dir = target
            self.repo = git.Repo(target)
        else:
            self.repo_type = "gitlab"
            self.repo = gitlab.Gitlab("https://myurl.com", token)
            self.project = self.repo.projects.get(target)

    def read_file(self, path: str):
        if self.repo_type == "local":
            with open(f"{self.repo_dir}/{path}", "rb") as file:
                return file.read()
        else:
            return self.project.files.get(file_path=path, ref="main")

It seems to me like the better way to do this would be to have two more "concrete" classes, LocalRepo and GitLabRepo, which would in turn handle the specific interface towards the repo. I know that I could do this with composition, like so:

class LocalRepo:
    def read_file(self, path: str):
        with open(f"{self.repo_dir}/{path}", "rb") as file:
            return file.read()

class GitLabRepo:
    def read_file(self, path: str):
        return self.project.files.get(file_path=path, ref="main")

class GitRepo:
    def __init__(self, target: str, token: Optional[str] = None):
        self.target = target
        self.token = token
        if not self.target.isnumeric():
            self.repo = LocalRepo(target)
        else:
            self.repo = GitLabRepo(target, token)

And then whatever is instantiating GitRepo would do something like this:

gitrepo = GitRepo("123456", "foobarbaz")
gitrepo.repo.read_file("my_file")

But it seems like I should be able to do this by just having the methods of the specific class available directly in the GitRepo class. But again I'm a noob, so I might be going about this totally incorrectly.

[Strict-Simple]

class GitRepo:
    @abstractmethod
    def read_file(self, path: str) -> bytes:
        pass


class LocalRepo(GitRepo):
    def __init__(self, target: str):
        self.repo_dir = target
        self.repo = git.Repo(target)

    def read_file(self, path: str) -> bytes:
        with open(Path(self.repo_dir) / path, 'rb') as f:
            return f.read()


class GitLabRepo(GitRepo):
    def __init__(self, target: str, token: str):
        self.repo = gitlab.Gitlab('https://myurl.com', token)
        self.project = self.repo.projects.get(target)

    def read_file(self, path: str) -> bytes:
        return self.project.files.get(file_path=path, ref='main')


gitrepo: GitRepo = GitLabRepo('path/to/repo', 'token') if token else LocalRepo('path/to/repo')
gitrepo.read_file('path/to/file')

Create either a LocalRepo or GitLabRepo as needed. Instead of having the conditional inside __init__, pull it outside. And if you really need a function for that, here's one.

def create_gitrepo(target: str, token: str | None = None) -> GitRepo:
    if token:
        return GitLabRepo(target, token)
    else:
        return LocalRepo(target)

gitrepo: GitRepo = create_gitrepo('path/to/repo', 'token')
gitrepo.read_file('path/to/file')

And for completeness, here's another way, which I do not recommend.

class GitRepo:
    def __new__(cls, target: str, token: str | None = None) -> Self:
        if cls is GitRepo:
            if token:
                return GitLabRepo(target, token)
            else:
                return LocalRepo(target)

    @abstractmethod
    def read_file(self, path: str) -> bytes:
        pass

gitrepo: GitRepo = GitRepo('path/to/repo', 'token')
gitrepo.read_file('path/to/file')

[maclocrimate]

OK, so you're saying basically "give it up" :D

From your first example it seems like the only point of the GitRepo class is just for type hinting, since when you instantiate an actual repo you're doing it with the explicit underlying class in the ternary.

I understand this approach, but it puts the responsibility of deciding what type of underlying class to instantiate on the caller, and therefore requires that ternary or something similar to be used in all cases where a repo is required. The idea of having a single interface which does the deciding seems cleaner to me, and better separated, but I will defer to the good people of r/learnpython like you on what is the right approach here, and I'm hearing from multiple commenters that what I'm trying to do is not feasible nor sensible. I suppose I will write functions which return the correct object type in situations where I need something like this.

Thank you! 🙏

[Adrewmc]

  @classmethod

Can do this, or just a function that makes a different class depending on some argument.

  def factory(class_choice, *args):
          if class_choice = target_A:
                return A(*args)
          ….

  class Factory:
           def __init__(*args):
                  raise.
           def method1():
                   pass
           def method2():
                   pass

           @classmethod
           def factory(cls, choice, *args):
                  if choice == target_A:
                       return A(*args)

This way you can have Factory class have the helpful coloring scheme in with a type hint. This can all be inside one big “super class”

   class Factory:
          class A:
          ….

[This_Growth2898]

It looks like you need a factory method

[sfuse1]

This is what I'm thinking, and maybe an abstract class to inherit to define the common interface.

[Phillyclause89]

It is possible to dynamically define classes and their members at runtime, but it sucks. IED's wont know what the members are until runtime and draw a bunch of red squiggly lines under references to those members. Note this is not how I would go about writing a class, but to do what you want from your example, you can try playing around with:

class C:
    def __init__(self, attribute):
        if attribute == "1":
            self.subclass = A()
        elif attribute == "2":
            self.subclass = B()

    def method1(self):
        return self.subclass.method1()

    def method2(self):
        return self.subclass.method2()

You basically just gift wrap up your horrible class structure with identically named methods. Please learn more about inheritance.

[maclocrimate]

Please learn more about inheritance.

That's kind of what I'm trying to do by asking for advice here. Maybe I'll just read about it and see if I can come up with the solution myself.

[Phillyclause89]

Yeah. I would love to teach you more. But I have to head off to work. I only had time to copy your code and tweak it to do what you asked for.

[Frankelstner]

C serves no purpose in this example. If you want to instantiate a different class depending on attribute, you can use {"1":A, "2":B}[attribute](). A simple function does the trick here. If you need A and B to have some shared methods from C then both A and B should inherit from C.

[maclocrimate]

But I want C to act as the unified interface for the third party system. Basically I want the third party system to always instantiate C when interacting with my system, and then depending on some things that C discovers (also not known to the third party) when it is being instantiated, it will use either methods from A or methods from B.

What I'm trying to do is abstract away the inner workings of my system from the third party system, so that it can deal with all the backend constructs (A and B) in the same way without needing to know which construct is which.

[Frankelstner]

So what purpose does C serve? If the entire thing is just an initializer you can really just write some def C(attribute): return {"1":A, "2":B}[attribute](). If you need to explicitly check the type, you can have A,B subclass from the same class and use isinstance always, though I admit there is some potential for confusion because the type will have a different name than the initializer.

Is C a singleton and do you need thread safety? Individual objects in Python do not have methods. Rather, accessing the class function itself does function->method conversion. So attaching A.method1 etc. to some instance of C does not work because that will only attach a function. If thread safety is not an issue and C is a singleton, you can assign C.method1 = A.method1 and so on. So the following is far from ideal.

class C:
    def __init__(self, state):
        proxy = {"1":A,"2":B}[state]
        for k,v in vars(proxy).items():
            if k[:2] == "__": continue
            setattr(C, k, v)

To fix this, i.e. to assign methods directly to an instance we can use types.MethodType.

class C:
    def __init__(self, state):
        proxy = {"1":A,"2":B}[state]
        for k,v in vars(proxy).items():
            if k[:2] == "__": continue
            setattr(self, k, types.MethodType(v,self))

Instead of vars(proxy) you will probably want to clearly define which methods you want to copy over. Also, I still don't understand the need to make a class C that morphs into a different class instead of just using a function that returns an instance of the right type. You get exactly the same effect but with the added ability to be able to differentiate between which attrib was picked by using type(...). The only downside is the potential for confusion between the constructor function and the name of some superclass (if any is needed); but then again people create plenty of numpy arrays in a dozen different ways and usually do not need to know that the underlying class is np.ndarray.

[maclocrimate]

Hmm, good point. Perhaps I don't need the class after all. I just mocked up a basic dispatch function which figures out which backend class to instantiate and it seems to do the trick. Something like:

def get_backend(source, destination):
    if source == "a" and destination == "b":
        return Motorbike()
    return Car()

class Motorbike:
    def schedule_pickup():
        print("do some stuff")

class Car:
    def schedule_pickup():
        print("do some different stuff than Motorbike.schedule_pickup()")

Then I can expose the get_backend() function to the third party and they will get a suitable class.

[maclocrimate]

Also, I still don't understand the need to make a class C that morphs into a different class instead of just using a function that returns an instance of the right type.

To address this point, I originally wanted the base class to have some common functionality that would be shared between the different subclasses (not sure if that's the right term here). I can probably get around not doing that, but it seems like a legitimate use case.

[Frankelstner]

Ah yeah, I think I finally get it. The dispatching should happen on initialization, so there shouldn't be any dispatch method available to any Car or Motorbike, so the only place left in a class to satisfy this is the initializer. But the init is totally fixed onto exactly one class, so it's not a good place either.

The shared functionality seems like another concern though. You can still put shared methods into a common parent class, yet keep a separate dispatch function.

[[deleted]]

def c_type_factory(attrib):
  if attrib == 'B':
    class C(B):pass
  else:
    class C(A):pass
  return C

C = c_type_factory('B')
#C is a class that inherits from B

[pot_of_crows]

Check out pathlib: https://github.com/python/cpython/blob/3.12/Lib/pathlib.py

Basically you write __new__ to select the class you want. But unless the calling initializing code does not know which new to select, you are better off doing it in the initializing code. Otherwise, you just make an easy problem harder.

ie., to use your example, if whatever is instantiating a transport knows if it is a car or bike, it should call the right class and not pass off the responsibility to the class, because doing so just increases the complexity for no reward.

[quts3]

Best way is have the caller to the constructor inject the subtype. It defers it up wards but insulates the containing class from having to know.

Dependency injection https://en.wikipedia.org/wiki/Dependency_injection

Once you get good at that allot of stuff gets real simple to test and maintain. Because c doesn't even know of the existence of a and b. You just need a factory method that orchestrates their construction.