Я пишу платформу на 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)
Любое понимание или общие комментарии будут оценены, Ура :)
СТАРЫЙ РЕДАКТИРОВАНИЕ: делать что-то вроде:
#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. Однако это решение беспорядочное.