Обсуждение множественного наследования против композиции для проекта (+ другие вещи)

Question

Я пишу платформу Python для симуляции распределенных скоплений датчиков. Идея заключается в том, что конечный пользователь может написать собственный узел, состоящий из поведения SensorNode (связь, ведение журнала и т. Д.), А также реализовать ряд различных датчиков.

Пример ниже кратко демонстрирует концепцию.

#prewritten
class Sensor(object):
  def __init__(self):
    print "Hello from Sensor"
  #...

#prewritten
class PositionSensor(Sensor):
  def __init__(self):
    print "Hello from Position"
    Sensor.__init__(self)
  #...

#prewritten
class BearingSensor(Sensor):
  def __init__(self):
    print "Hello from Bearing"
    Sensor.__init__(self)
  #...

#prewritten
class SensorNode(object):
  def __init__(self):
    print "Hello from SensorNode"
  #...

#USER WRITTEN
class MySensorNode(SensorNode,BearingSensor,PositionSensor):
  def CustomMethod(self):
    LogData={'Position':position(), 'Bearing':bearing()} #position() from PositionSensor, bearing() from BearingSensor
    Log(LogData) #Log() from SensorNode

НОВОЕ РЕДАКТИРОВАНИЕ:

Во-первых, обзор того, чего я пытаюсь достичь: Я пишу симулятор для моделирования алгоритмов разведки роя с особым акцентом на мобильные сенсорные сети Эти сети состоят из множества маленьких роботов, передающих данные отдельных датчиков для создания сложной сенсорной карты окружающей среды.

Основная цель этого проекта - разработать платформу для моделирования, которая предоставляет абстрактные интерфейсы для датчиков, чтобы те же функции, реализованные пользователем, могли быть напрямую перенесены в роботизированный рой со встроенным Linux. Поскольку целью является роботизированная реализация, мне нужно спроектировать так, чтобы программный узел вел себя одинаково и имел доступ только к информации, которую имел бы физический узел.

Как часть механизма моделирования, я буду предоставлять набор классов, моделирующих различные типы датчиков и различные типы узлов датчиков. Я хочу абстрагироваться от всей этой сложности от пользователя так, чтобы все, что пользователь должен сделать, это определить, какие датчики присутствуют на узле, и какой тип узла датчика (мобильный, фиксированное положение) реализуется.

Вначале я думал, что каждый датчик будет предоставлять метод read (), который будет возвращать соответствующие значения, однако, прочитав ответы на вопрос, я вижу, что, возможно, было бы полезно использовать более описательные имена методов (.distance (), .position (), .bearing () и т. д.).

Первоначально я хотел использовать отдельные классы для датчиков (с общими предками), чтобы более технический пользователь мог легко расширить один из существующих классов, чтобы создать новый датчик, если он пожелает. Например:

Sensor
  |
DistanceSensor(designed for 360 degree scan range)
    |           |           |
IR Sensor   Ultrasonic    SickLaser
(narrow)    (wider)       (very wide)

Причина, по которой я изначально думал о множественном наследовании (хотя оно и частично нарушает отношения наследования IS-A), была вызвана принципом, лежащим в основе системы моделирования. Позвольте мне объяснить:

Внедренный пользователем MySensorNode не должен иметь прямого доступа к своей позиции в среде (сродни роботу, доступ косвенный через интерфейс датчика), аналогично датчики не должны знать, где они находятся. Однако это отсутствие прямых знаний создает проблему, поскольку все возвращаемые значения датчиков зависят от их положения и ориентации в среде (которую необходимо смоделировать для получения правильных значений).

SensorNode, как класс, реализованный в библиотеках симуляции, отвечает за отрисовку MySensorNode в среде Pygame - таким образом, это единственный класс, который должен иметь прямой доступ к положению и ориентации узла датчика в среде.

SensorNode также отвечает за перемещение и вращение в окружающей среде, однако это перемещение и вращение является побочным эффектом приведения двигателя в действие.

Под этим я подразумеваю, что роботы не могут напрямую изменять свое положение в мире, все, что они могут сделать, - это обеспечивать питание двигателей, а движение внутри мира является побочным эффектом взаимодействия двигателей с окружающей средой. Мне нужно точно смоделировать это в симуляции.

Итак, для перемещения пользовательские функции могут использовать:

motors(50,50)

Этот вызов, как побочный эффект, изменит положение узла в мире.

Если SensorNode был реализован с использованием композиции, SensorNode.motors (...) не сможет напрямую изменять переменные экземпляра (например, положение), и MySensorNode.draw () не будет разрешен в SensorNode.draw (), поэтому SensorNode imo должен быть реализован с использованием наследования.

С точки зрения датчиков, преимущество композиции для такой проблемы очевидно, MySensorNode состоит из нескольких датчиков - достаточно сказать.

Однако проблема, как я вижу, заключается в том, что Сенсорам нужен доступ к их положению и ориентации в мире, и если вы используете композицию, вы получите вызов, подобный:

>>> PosSensor.position((123,456))
(123,456)

Опять же, подумав, вы можете передать себя датчику при инициализации, например:

PosSensor = PositionSensor(self)

потом позже

PosSensor.position()

однако для этого PosSensor.position () потребуется доступ к информации, локальной для экземпляра (передаваемой как self во время init ()), так зачем вообще вызывать PosSensor, если вы можете получить доступ к информации локально? Также передача вашего экземпляра объекту, из которого вы состоите, кажется просто не совсем правильной, пересекая границы инкапсуляции и сокрытия информации (даже несмотря на то, что python мало что делает для поддержки идеи сокрытия информации).

Если бы решение было реализовано с использованием множественного наследования, эти проблемы исчезли бы:

class MySensorNode(SensorNode,PositionSensor,BearingSensor):
  def Think():
    while bearing()>0:
      # bearing() is provided by BearingSensor and in the simulator
      # will simply access local variables provided by SensorNode
      # to return the bearing. In robotic implementation, the
      # bearing() method will instead access C routines to read
      # the actual bearing from a compass sensor
      motors(100,-100)
      # spin on the spot, will as a side-effect alter the return
      # value of bearing()

    (Ox,Oy)=position() #provided by PositionSensor
    while True:
      (Cx,Cy)=position()
      if Cx>=Ox+100:
        break
      else:
        motors(100,100)
        #full speed ahead!will alter the return value of position()

---

Надеюсь, эта редакция прояснила некоторые вещи, если у вас есть какие-либо вопросы, я с радостью постараюсь их прояснить

СТАРЫЕ ВЕЩИ:

Когда создается объект типа MySensorNode, необходимо вызывать все конструкторы из суперклассов. Я не хочу усложнять пользователю необходимость писать собственный конструктор для MySensorNode, который вызывает конструктор из каждого суперкласса. В идеале, я бы хотел, чтобы это произошло:

mSN = MySensorNode()
# at this point, the __init__() method is searched for
# and SensorNode.__init__() is called given the order
# of inheritance in MySensorNode.__mro__

# Somehow, I would also like to call all the other constructors
# that were not executed (ie BearingSensor and PositionSensor)

Любое понимание или общие комментарии приветствуются, Ура :) 1062 *

СТАРЫЙ РЕДАКТИРОВАТЬ: Делать что-то вроде:

#prewritten
class SensorNode(object):
  def __init__(self):
    print "Hello from SensorNode"
    for clss in type(self).__mro__:
      if clss!=SensorNode and clss!=type(self):
        clss.__init__(self)

Это работает, так как self является экземпляром MySensorNode. Однако это решение грязное.

---

Answer 1

Архитектура сенсора может быть решена с помощью композиции, если вы хотите придерживаться своего первоначального дизайна карты данных. Вы, кажется, плохо знакомы с Python, поэтому я постараюсь свести идиомы к минимуму.

class IRSensor:
    def read(self): return {'ir_amplitude': 12}

class UltrasonicSensor:
    def read(self): return {'ultrasonic_amplitude': 63}

class SickLaserSensor:
    def read(self): return {'laser_amplitude': 55}

class CompositeSensor:
    """Wrap multiple component sensors, coalesce the results, and return
    the composite readout.
    """
    component_sensors = []

    def __init__(self, component_sensors=None):
        component_sensors = component_sensors or self.component_sensors
        self.sensors = [cls() for cls in component_sensors]

    def read(self):
        measurements = {}
        for sensor in self.sensors:
            measurements.update(sensor.read())
        return measurements

class MyCompositeSensor(CompositeSensor):
    component_sensors = [UltrasonicSensor, IRSensor]


composite_sensor = MyCompositeSensor()
measurement_map = composite_sensor.read()
assert measurement_map['ultrasonic_amplitude'] == 63
assert measurement_map['ir_amplitude'] == 12

Архитектурная проблема, которую вы описываете с приводами, решается с помощью миксинов и прокси (через __getattr__), а не наследования. (Прокси может быть хорошей альтернативой наследованию, потому что объекты для прокси могут быть связаны / не связаны во время выполнения. Кроме того, вам не нужно беспокоиться об обработке всей инициализации в одном конструкторе с использованием этой техники.)

class MovementActuator:
    def __init__(self, x=0, y=0):
        self.x, self.y = (x, y)

    def move(self, x, y):
        print 'Moving to', x, y
        self.x, self.y = (x, y)

    def get_position(self):
        return (self.x, self.y)

class CommunicationActuator:
    def communicate(self):
        return 'Hey you out there!'

class CompositeActuator:
    component_actuators = []

    def __init__(self, component_actuators=None):
        component_actuators = component_actuators \
            or self.component_actuators
        self.actuators = [cls() for cls in component_actuators]

    def __getattr__(self, attr_name):
        """Look for value in component sensors."""
        for actuator in self.actuators:
            if hasattr(actuator, attr_name):
                return getattr(actuator, attr_name)
        raise AttributeError(attr_name)


class MyCompositeActuator(CompositeActuator):
    component_actuators = [MovementActuator, CommunicationActuator]

composite_actuator = MyCompositeActuator()
assert composite_actuator.get_position() == (0, 0)
assert composite_actuator.communicate() == 'Hey you out there!'

И, наконец, вы можете бросить все это вместе с простым объявлением узла:

from sensors import *
from actuators import *

class AbstractNode:
    sensors = [] # Set of classes.
    actuators = [] # Set of classes.
    def __init__(self):
        self.composite_sensor = CompositeSensor(self.sensors)
        self.composite_actuator = CompositeActuator(self.actuators)

class MyNode(AbstractNode):
    sensors = [UltrasonicSensor, SickLaserSensor]
    actuators = [MovementActuator, CommunicationActuator]

    def think(self):
        measurement_map = self.composite_sensor.read()
        while self.composite_actuator.get_position()[1] >= 0:
            self.composite_actuator.move(100, -100)

my_node = MyNode()
my_node.think()

Это должно дать вам представление об альтернативах жесткой системе типов. Обратите внимание, что вам вообще не нужно полагаться на иерархию типов - просто внедрите (потенциально неявный) общий интерфейс.

МЕНЬШЕ СТАРЫЙ:

После более внимательного прочтения вопроса я вижу, что у вас есть классический пример алмазного наследования , который является злом, которое заставляет людей бежать к единственному наследованию.

Вы, вероятно, не хотите, чтобы это начиналось, поскольку иерархия классов означает присед в Python. Что вы хотите сделать, это сделать SensorInterface (минимальные требования для датчика) и иметь набор «смешанных» классов, которые имеют полностью независимую функциональность, которая может быть вызвана с помощью методов с различными именами. В вашей структуре датчика вы не должны говорить что-то вроде isinstance(sensor, PositionSensor) - вы должны говорить что-то вроде «может ли этот датчик определять местоположение?» в следующем виде:

def get_position(sensor):
    try:
        return sensor.geolocate()
    except AttributeError:
        return None

Это сердце философии типизации утки и EAFP (Проще просить прощения, чем разрешения), оба из которых охватывает язык Python.

Вам, вероятно, следует описать, какие методы на самом деле будут реализовывать эти датчики, чтобы мы могли описать, как вы можете использовать классы mixin для вашей архитектуры плагинов.

OLD:

Если они пишут код в модуле, который помещается в пакет плагинов или что у вас есть, вы можете волшебным образом использовать классы для них, когда вы импортируете их модули плагинов. Что-то вроде этого фрагмента (не проверено):

 import inspect
 import types

 from sensors import Sensor

 def is_class(obj):
     return type(obj) in (types.ClassType, types.TypeType)

 def instrumented_init(self, *args, **kwargs):
     Sensor.__init__(self, *args, **kwargs)

 for module in plugin_modules: # Get this from somewhere...
     classes = inspect.getmembers(module, predicate=is_class)
     for name, cls in classes:
         if hasattr(cls, '__init__'):
             # User specified own init, may be deriving from something else.
             continue 
         if cls.__bases__ != tuple([Sensor]):
             continue # Class doesn't singly inherit from sensor.
         cls.__init__ = instrumented_init

Вы можете найти модули в пакете с другой функцией.

Answer 2

Вот частичное решение:

class NodeMeta(type):
    def __init__(cls, name, bases, d):
        setattr(cls, '__inherits__', bases)

class Node(object):
    __metaclass__ = NodeMeta

    def __init__(self):
        for cls in self.__inherits__:
            cls.cls_init(self)

class Sensor(Node):
    def cls_init(self):
        print "Sensor initialized"

class PositionSensor(Sensor):
    def cls_init(self):
        print "PositionSensor initialized"
        self._bearing = 0

    def bearing(self):
        # calculate bearing:
        return self._bearing

class BearingSensor(Sensor):
    def cls_init(self):
        print "BearingSensor initialized"
        self._position = (0, 0)

    def position(self):
        # calculate position:
        return self._position

# -------- custom sensors --------

class CustomSensor(PositionSensor, BearingSensor):
    def think(self):
        print "Current position:", self.position()
        print "Current bearing:", self.bearing()

class CustomSensor2(PositionSensor, BearingSensor, Sensor):
    pass

>>> s = CustomSensor()
PositionSensor initialized
BearingSensor initialized
>>> s.think()
Current position: (0, 9)
Current bearing: 0

Вам придется переместить ваш код __init__ из подклассов Node в другой метод (я использовал cls_init).

Редактировать: Я опубликовал это, прежде чем увидел ваши обновления; Я перечитал ваш вопрос и при необходимости обновлю это решение.

Answer 3

super вызывает следующий класс в списке mro. Это работает, даже если вы пропустите __init__ форму некоторого класса.

class A(object):
  def __init__(self):
    super(A,self).__init__()
    print "Hello from A!"

class B(A):
  def __init__(self):
    super(B,self).__init__()
    print "Hello from B!"

class C(A):
  def __init__(self):
    super(C,self).__init__()
    print "Hello from C!"

class D(B,C):
  def __init__(self):
    super(D,self).__init__()
    print "Hello from D!"

class E(B,C):
  pass

Пример:

>>> x = D()
Hello from A!
Hello from C!
Hello from B!
Hello from D!
>>> y = E()
Hello from A!
Hello from C!
Hello from B!
>>> 

Редактировать: Переписал ответ. (Еще раз)