Я пишу платформу python для моделирования распределенных датчиков. Идея состоит в том, что конечный пользователь может написать пользовательский Node, состоящий из поведения 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. Поскольку роботизированная реализация является целью, мне нужно сконструировать так, чтобы программное обеспечение Node вело себя одинаково и имело только доступ к информации, которую имел бы физический Node.
В качестве части механизма моделирования я буду предлагать набор классов, имитирующих различные типы датчиков и различные типы датчиков node. Я хочу отвлечь всю эту сложность от пользователя, чтобы все, что должен сделать пользователь, определить, какие датчики присутствуют на node, и какой тип датчика Node (мобильное фиксированное положение) реализуется.
Мое первоначальное мышление заключалось в том, что каждый датчик предоставит метод 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 - таким образом, это единственный класс, который должен иметь прямой доступ к положению и ориентации датчика Node в пределах окружающая среда.
SensorNode также отвечает за перевод и вращение в среде, однако этот перевод и вращение являются побочным эффектом приведения в действие двигателя.
Что я имею в виду, так это то, что роботы не могут напрямую изменить свое положение в мире, все, что они могут сделать, это обеспечить мощность для двигателей, а движение в мире - это побочный эффект взаимодействия моторов с окружающей средой. Мне нужно точно это моделировать в симуляции.
Итак, чтобы двигаться, пользовательская функциональность может использовать:
motors(50,50)
Этот вызов в качестве побочного эффекта изменит положение Node в мире.
Если 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)
Любое понимание или общие комментарии будут оценены, Приветствия:)
OLD EDIT: Выполнение чего-то вроде:
#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)
Это работает, поскольку сам является экземпляром MySensorNode. Однако это решение беспорядочно.