I've been trying to get this to work for quite some time now, and still don't see the light at the end of the tunnel. And since i'm not the sharpest tool in the shed, i'm happy to ask the silly questions as i'm sure i'm not the only tool needing help ;)
quick overview:
I'm trying to make my arduino do everything over I2C. I'm using the LiquidCrystal_I2C library for the display (working fine). But now I want to use a TC74A* temperature sensor to get the temp. Since I want a few of them I decided to write a little library for them. And I want to initialize them in the main program using something like
int TC74A_Control::readTemp(??)
{
??.beginTransmission(sensorAddress);
??.write(0);
??.endTransmission();
??.requestFrom(sensorAddress, 1);
while(??.available() == 0);
int t = ??.read();
return t;
}
So how should I do this? What should I change the question marks for... I'm sure it has something to do with pointers and alls that jazz, but I can't put my finger on it...
but when i compile this, well, it all goes pear shaped.
trying to figure out the error messages, but if anyone has any input, it would be greatly appreciated...
I see what you did there, you just passed the address and started the wire comm inside the library. This is definitely another way of doing it. Any reason why only the address and not the entire object? I'm guessing it's cleaner that way? Maybe I was just making it too complicated for myself...
The big question is "where does the object need to be visible?"
In OOP, you want to watch out for a code property called 'linkage': how many other classes does an object need to know about in order to work, and by extension, how many header files you you need to include in the header for that class?
Linkage makes problems with one chunk of code propagate to another, so you generally want as little as you can get.
As an example, let's say we have two classes named Foo and Bar, and we want Foo to use some feature that Bar provides.
One solution is to create an instance of Bar in the main code and pass it to an instance of Foo. That means we have linkage from Bar to the main code (which creates the object) and the Foo class (which uses the object). We also have linkage from the main code to Foo.
Another solution is to let the Foo class create a Bar object internally. That gives us linkage from the main code to Foo, and from Foo to Bar. The main code doesn't need to know anything about Bar, so that way of arranging the code has less linkage. If you decide you don't really need Bar and want to merge the features it provides into the Foo class, your main code doesn't need to know or care about it.
To make things more complicated, let's add a class named Bazz that supplies information necessary to create the Bar object, and let's assume that it needs to be created in the main code. There are several ways to organize that:
We could have the main code create a Bazz object, use that to create a Bar object, then pass the Bar object to Foo.
We could have the main code create a Bazz object, pass that to Foo, and let Foo configure the Bar object.
We could have the main code create a Bazz object, pull simple values from that (ints, strings, etc) and pass those values to Foo so it can configure the Bar object it creates internally.
That last option sounds more complicated, but it eliminates any linkage from Bazz to the Foo or Bar classes, and that's a good thing. It means you can create and configure a Foo object without actually using a Bazz object, just feeding the config methods values of the appropriate type. You can also create a fake class with the same configuration methods as Foo to see if your main code is doing the setup properly.
There are times when it's appropriate to pass an instance of one class to another, usually to simplify communication between widely separated sections of code. If you can replace an object parameter with a simpler type of parameter though, it's usually a good idea to do so.
Linkage makes problems with one chunk of code propagate to another, so you generally want as little as you can get.
I'm with Mike here. Tight coupling between classes can create major problems - and these problems tend to compound exponentially. What makes for frustration and hair-pulling in an Arduino-scale project can be complete show-stoppers in larger systems.
Aha, I see what you are getting at. I guess I was getting a bit overboard with making my own classes. I was using one of your touchscreens, the tft lcd shield with touch screen (great board btw!), and making different kinds of buttons to use in another project. And since it worked wonders simplifying the main program there, I went on using it here. But it'll just end up making too much linkage between the different parts of the program. I'll end up only passing the address along, like you suggested in a previous answer. I also had this weird idea that once a Wire instance was created, it should be passed around the entire program... Anyway, thanks for making this very clear, and keep up the good work (and good products)!
