<p>Hello, I'm new to golang.
I'm working on a project of mine and I am not sure how to proceed.
I am used to regular ordinary OOP, so I guess I need a little help to shift mindset.</p>
<p>I currently have a grovepi board, to which are attached some sensors.
I have a grovepi.go that provides functions to read digitally or anologically from the grovepi i2c connection.
I also have a sensors.go providing sensors stuff.</p>
<p>I need to read from the sensors.</p>
<p>Shall I have a function like</p>
<p>func(g *GrovePi) Read(sensor Sensor) (Measurement, error) {
return sensor.Read()
}</p>
<p>or</p>
<p>func(s Sensor) Read(grovePi *GrovePi) (Measurement, error) {
return grovePi.ReadAnalog(2)
}</p>
<p>?</p>
<p>Quite confused on this.
Thanks!</p>
<hr/>**评论：**<br/><br/>niondir: <pre><p>How about using an interface like io.Reader to read. You can then use some decoder to decode the content. That way you keep your code clean an separate without binding too much logic to entities at all.</p>
<p>There are decoders for hex and base64 in the stdlib that you can use as examples.</p></pre>gobwas: <pre><p>It depends on data that Sensor holds. If, for example, Sensor is just some sensor id, then I prefer to pass it as an argument.</p>
<p>You could try to name that function more implicitly. That is, technically those calls the same:</p>
<p>func read(a, b) m
func read(b, a) m</p></pre>md2perpe: <pre><p>If you have only one GrovePi board, why do you have a GrovePi structure? You're not going to create several GrovePi variables, are you? And if you anyway go with a GrovePi structure, then if every sensor belongs to <em>one</em> GrovePi board, then the Sensor structure could contain a pointer to the GrovePi structure so you won't have to pass both a board and a sensor to the function.</p></pre>Redundancy_: <pre><p>Neither of these function signatures make sense to me.</p>
<p>In (1) you're passing in a sensor and then reading from it, on a function that's on a GrovePi. The function doesn't have anything to do with the object that it's on, which is odd.</p>
<p>In (2) you're passing a GrovePi to a sensor and then reading from the GrovePi. Again, it has nothing to do with the object that it's on.</p>
<p>Unused arguments are a code smell, especially if you're not trying to satisfy an arkward interface.</p></pre>LC2712: <pre><p>I feel the same, but I can't find a solution. Can you?</p></pre>Redundancy_: <pre><p>I'm not sure I understand the problem well enough to do that.</p>
<p>If the relationship is that sensors belong to a board, you have the questions -</p>
<ul>
<li>Does my board have an array of sensors, or a way to look them up? </li>
<li>Does a sensor know enough to handle reading by itself?</li>
<li>Does it make sense to expose sensors to things that interact with a board? </li>
<li>Can I encapsulate details of that relationship by having the board handle things?</li>
</ul></pre>LC2712: <pre><ul>
<li><p>I am using grove sensors via raspberry + grovepi. Sensor are loaded from a configuration file. Every Sensor (well, groups of them) is read in a different way: digital or analog, with a pause or more during the reading process (100 ms and read, or 100 ms and read1 and 200ms and read2), and can produce different types of output (binary -> needs to be parsed, float, string, whatever) and can also return a splice with more info(some sensors only produce one value, like light sensors, but others could return e.g. temperature and humidity together, because that's how they're built).
I load them and "go read()" all of them, so they can concurrently write into an api channel that will send all the info to a server.
The idea is that every reader knows how to produce the low-level command to read the sensor and return the final result: i would say that read() and parse() are more personal to the sensor.</p></li>
<li><p>It should, cause every sensor is a specific case</p></li>
<li><p>That's what I was thinking, but at the same time they need to read and parse in a way that is specific to them, cause they produce different data, and this way is at the same time very specific of the grovepi using i2c to communicate. maybe grovepi should be a property of the sensor?
I don't know if they would use the same command to communicate with other boards.</p></li>
<li><p>Probably the solution, but I am still not very sure how to do it</p></li>
</ul>
<p>Thank you :)</p></pre>Redundancy_: <pre><p>I'd just make the observation that a lot of the OO <em>principles</em> work in Go, the major difference is that you don't use inheritance.</p></pre>LC2712: <pre><p>Ok this is great, but do you have any tips to get me pointed to the right direction?</p></pre>Redundancy_: <pre><p><a href="http://spf13.com/post/is-go-object-oriented/" rel="nofollow">http://spf13.com/post/is-go-object-oriented/</a> might help</p></pre>
