Let me start with some real world observations. A sensor is a piece of hardware that measures an aspect or some aspects of the world. The more complex sensors can measure different aspects. The IR sample for example can measure both distance and angle. Sometimes a sensor can measure different aspects at the same time, sometimes it needs to be configured to measure one aspect out of several possibilities.

In leJOS we say that to measure a specific aspect the sensor must be in the right mode for this. To measure reflected light a light sensor must be in RedMode. To measure ambient light it must be in AmbiantMode.

There are basicly two ways to implement the idea of a mode. One is to have a sensor class that can be configured for each mode. The sensor class would then need a method like setMode. There are drawbacks to this approach. The biggest one is that you can never be sure that a sensor is in the right mode, some other thread might have changed it.
Another approach is to have a different class for each mode that a sensor supports. This is the solution leJOS adapted. The RedMode class always measures reflected light, the ambientMode class always measures ambient light. This solution does not have the drawback of the previous solution. One can even have the two classes active at the same time. There are drawback though. Both classes use the same piece of hardware, so they probably share a lot of functionality. Also, users think in terms of sensors, not in terms of modes. To overcome this drawback leJOS bundles the mode classes belonging to one sensor in a sensor class. This class provides the ability to really talk to the sensor and configure it for each mode. It also provide the mode classes to the user by means of the getMode methods. As the mode classes are tightly linked to the sensor class and share the resources provided by the sensor class it is logical design decision to implement them as inner classes.

As to the question that started the question about inner classes. I do not think there is a need for an EV3DEV alternative for mode classes. They do not need an ev3dev implementation as it is the sensor class that actually talks to the sensor, not the mode class.

Aswin

Doubt about Sensor implementation using Inner Classes #121

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions