如何以最契合OOP范式的方式实现同一抽象的多种定义？

Great question—this is exactly the kind of design problem where OOP principles can feel tricky but also shine when you lean into abstraction properly. Let’s break this down into your specific scenario first, then expand to the broader abstract definition problem you’re curious about.

1. Solving the Mutual Method Dependency Problem #

Your initial idea to extract shared logic into a separate method is absolutely on the right track—it avoids both code redundancy and fragile one-way dependencies, while eliminating the risk of infinite recursion. The key is to anchor both methods to a single source of truth (a core state or abstract logic) instead of letting them rely on each other.

Let’s use a concrete Python example: imagine a Temperature class where to_celsius() and to_fahrenheit() can be derived from each other. Instead of picking one as the "source" method, we’ll define an abstract core method that both rely on:

from abc import ABC, abstractmethod

class Temperature(ABC):
    # Define an abstract core method subclasses must implement
    @abstractmethod
    def _get_kelvin(self) -> float:
        """Return temperature in Kelvin (our neutral baseline)."""
        pass

    # Both public methods depend on the core baseline, not each other
    def to_celsius(self) -> float:
        return self._get_kelvin() - 273.15

    def to_fahrenheit(self) -> float:
        return (self._get_kelvin() - 273.15) * 9/5 + 32

# Subclass that stores temperature in Celsius
class CelsiusTemp(Temperature):
    def __init__(self, value: float):
        self._celsius = value

    def _get_kelvin(self) -> float:
        return self._celsius + 273.15

# Subclass that stores temperature in Fahrenheit
class FahrenheitTemp(Temperature):
    def __init__(self, value: float):
        self._fahrenheit = value

    def _get_kelvin(self) -> float:
        return (self._fahrenheit - 32) * 5/9 + 273.15

This approach:

• Eliminates redundancy: The conversion logic for Celsius/Fahrenheit is written once, based on the neutral Kelvin baseline.
• Avoids hard dependencies: Neither public method relies on the other—they both depend on the abstract core, which subclasses implement based on their stored state.
• Prevents recursion: No circular calls between public methods, since they both point to a single source of truth.

As for potential downsides? The only risk is over-abstracting if your shared logic is trivial (e.g., is_even() and is_odd()), but even then, extracting a _get_mod_2() method keeps things clean and maintainable.

2. Implementing Abstractions Defined by Multiple Abstract Groups #

For scenarios where one abstract concept can be defined by multiple sets of smaller abstractions, Python’s combination of abstract base classes (ABCs) and mixin classes is perfect. Mixins let you define default implementations for abstract contracts, so you can compose different groups of abstractions without being locked into a strict tree hierarchy.

Let’s extend the temperature example: suppose we have two sets of abstractions for temperature conversion:

• Set A: SupportsCelsius + SupportsFahrenheit
• Set B: SupportsKelvin + SupportsRankine

We can define these as separate ABCs, then create mixins to derive one set from the other:

from abc import ABC, abstractmethod

# First set of abstractions
class SupportsCelsius(ABC):
    @abstractmethod
    def to_celsius(self) -> float:
        pass

class SupportsFahrenheit(ABC):
    @abstractmethod
    def to_fahrenheit(self) -> float:
        pass

# Second set of abstractions
class SupportsKelvin(ABC):
    @abstractmethod
    def to_kelvin(self) -> float:
        pass

class SupportsRankine(ABC):
    @abstractmethod
    def to_rankine(self) -> float:
        pass

# Mixin: Derive Kelvin/Rankine from Celsius/Fahrenheit
class CelsiusFahrenheitToKelvinRankineMixin(SupportsKelvin, SupportsRankine):
    def to_kelvin(self) -> float:
        return self.to_celsius() + 273.15

    def to_rankine(self) -> float:
        return self.to_fahrenheit() + 459.67

# Mixin: Derive Celsius/Fahrenheit from Kelvin/Rankine
class KelvinRankineToCelsiusFahrenheitMixin(SupportsCelsius, SupportsFahrenheit):
    def to_celsius(self) -> float:
        return self.to_kelvin() - 273.15

    def to_fahrenheit(self) -> float:
        return self.to_rankine() - 459.67

# Example implementation: Implement only Set A, get Set B via mixin
class SimpleTemp(SupportsCelsius, SupportsFahrenheit, CelsiusFahrenheitToKelvinRankineMixin):
    def __init__(self, celsius: float):
        self._celsius = celsius

    def to_celsius(self) -> float:
        return self._celsius

    def to_fahrenheit(self) -> float:
        return self._celsius * 9/5 + 32

# Usage
temp = SimpleTemp(25)
print(temp.to_kelvin())   # 298.15
print(temp.to_rankine())  # 536.67

This setup lets you:

• Define abstract contracts independently.
• Compose them freely using mixins to avoid redundant code.
• Let subclasses choose which core abstractions to implement, with the rest automatically provided via mixins.

It’s a flexible way to handle cases where an abstract concept can be defined through multiple valid sets of requirements—without being constrained by a rigid class hierarchy.

内容的提问来源于stack exchange，提问作者abel1502