title: Discussion of multiple inheritance vs Composition for a project (+other things)
body: <p>I am writing a python platform for the simulation of distributed sensor swarms. The idea being that the end user can write a custom Node consisting of the SensorNode behaviour (communication, logging, etc) as well as implementing a number of different sensors.</p>
  
  <p>The example below briefly demonstrates the concept.</p>
  
  <pre><code>#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
  </code></pre>
  
  <h2>NEW EDIT:</h2>
  
  <p>Firstly an overview of what I am trying to achieve:
  I am writing a simulator to simulate swarm intelligence algorithms with particular focus on mobile sensor networks. These networks consist of many small robots communicating individual sensor data to build a complex sensory map of the environment.</p>
  
  <p>The underlying goal of this project is to develop a simulation platform that provides abstracted interfaces to sensors such that the same user-implemented functionality can be directly ported to a robotic swarm running embedded linux. As robotic implementation is the goal, I need to design such that the software node behaves the same, and only has access to information that an physical node would have.</p>
  
  <p>As part of the simulation engine, I will be providing a set of classes modelling different types of sensors and different types of sensor node. I wish to abstract all this complexity away from the user such that all the user must do is define which sensors are present on the node, and what type of sensor node (mobile, fixed position) is being implemented.</p>
  
  <p>My initial thinking was that every sensor would provide a read() method which would return the relevant values, however having read the responses to the question, I see that perhaps more descriptive method names would be beneficial (.distance(), .position(), .bearing(), etc).</p>
  
  <p>I initially wanted use separate classes for the sensors (with common ancestors) so that a more technical user can easily extend one of the existing classes to create a new sensor if they wish. For example:</p>
  
  <pre><code>Sensor
    |
  DistanceSensor(designed for 360 degree scan range)
      |           |           |
  IR Sensor   Ultrasonic    SickLaser
  (narrow)    (wider)       (very wide)
  </code></pre>
  
  <p>The reason I was initially thinking of Multiple Inheritance (although it semi-breaks the IS-A relationship of inheritance) was due to the underlying principle behind the simulation system. Let me explain:</p>
  
  <p>The user-implemented MySensorNode should not have direct access to its position within the environment (akin to a robot, the access is indirect through a sensor interface), similarly, the sensors should not know where they are. However, this lack of direct knowledge poses a problem, as the return values of the sensors are all dependent on their position and orientation within the environment (which needs to be simulated to return the correct values).</p>
  
  <p>SensorNode, as a class implemented within the simulation libraries, is responsible for drawing the MySensorNode within the pygame environment - thus, it is the only class that should have direct access to the position and orientation of the sensor node within the environment.</p>
  
  <p>SensorNode is also responsible for translation and rotation within the environment, however this translation and rotation is a side effect of motor actuation.</p>
  
  <p>What I mean by this is that robots cannot directly alter their position within the world, all they can do is provide power to motors, and movement within the world is a side-effect of the motors interaction with the environment. I need to model this accurately within the simulation.</p>
  
  <p>So, to move, the user-implemented functionality may use:</p>
  
  <pre><code>motors(50,50)
  </code></pre>
  
  <p>This call will, as a side-effect, alter the position of the node within the world. </p>
  
  <p>If SensorNode was implemented using composition, SensorNode.motors(...) would not be able to directly alter instance variables (such as position), nor would MySensorNode.draw() be resolved to SensorNode.draw(), so SensorNode imo should be implemented using inheritance.</p>
  
  <p>In terms of the sensors, the benefit of composition for a problem like this is obvious, MySensorNode is composed of a number of sensors - enough said.</p>
  
  <p>However the problem as I see it is that the Sensors need access to their position and orientation within the world, and if you use composition you will end up with a call like:</p>
  
  <pre><code>&gt;&gt;&gt; PosSensor.position((123,456))
  (123,456)
  </code></pre>
  
  <p>Then again - thinking, you could pass self to the sensor upon initialisation, eg:</p>
  
  <pre><code>PosSensor = PositionSensor(self)
  </code></pre>
  
  <p>then later</p>
  
  <pre><code>PosSensor.position()
  </code></pre>
  
  <p>however this PosSensor.position() would then need to access information local to the instance (passed as self during <strong>init</strong>()), so why call PosSensor at all when you can access the information locally? Also passing your instance to an object you are composed of just seems not quite right, crossing the boundaries of encapsulation and information hiding (even though python doesn't do much to support the idea of information hiding).</p>
  
  <p>If the solution was implemented using multiple inheritance, these problems would disappear:</p>
  
  <pre><code>class MySensorNode(SensorNode,PositionSensor,BearingSensor):
    def Think():
      while bearing()&gt;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&gt;=Ox+100:
          break
        else:
          motors(100,100)
          #full speed ahead!will alter the return value of position()
  </code></pre>
  
  <hr>
  
  <p>Hopefully this edit has clarified some things, if you have any questions I'm more than happy to try and clarify them</p>
  
  <h2>OLD THINGS:</h2>
  
  <p>When an object of type MySensorNode is constructed, all constructors from the superclasses need to be called. I do not want to complicate the user with having to write a custom constructor for MySensorNode which calls the constructor from each superclass. Ideally, what I would like to happen is:</p>
  
  <pre><code>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)
  </code></pre>
  
  <p>Any insight or general comments would be appreciated,
  Cheers :)</p>
  
  <p>OLD EDIT:
  Doing something like:</p>
  
  <pre><code>#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)
  </code></pre>
  
  <p>This works, as self is an instance of MySensorNode. However this solution is messy.</p>
  
  <hr>