dillonradio:
That makes it much clearer thanks.
I think I've figured out what I was missing. My sketch already uses the struct to make the sketch work on an array of LEDs but when making a library it just needs to work on one LED and then instances of the class handle the array of LEDs.
I think I still should be including the methods in the class as well as the candleProperties. I hope that sounds right?
There is magic in Paul's note above
PaulS:
Every time I start creating a struct, I end up determining that the instances should be smarter, and should have methods, like knowing how to add themselves to a list, so I end up refactoring the code to make the struct a class.
I recommend that instead of thinking about classes and structs, you think about Objects.
each instance of a Candle object has properties. An obvious analogy is a candle.
Candles have Color, Height, Diameter and they are lit or not lit. if you want to get/set these properties outside the instance of the class, you make them public, otherwise you make them private:
class Candle{
public:
private:
int Color;
int Height;
int Diameter;
bool isLit;
};
what will you do with a candle? Well you can lite it or put it out.... you want to be able to lite or put out any candle from anywhere, so you have to create public member functions:
class Candle{
public:
void lite();
void putOut();
private:
int Color;
int Height;
int Diameter;
bool isLit;
};
you also may want to know if it is burning or not:
class Candle{
public:
void lite();
void putOut();
bool isBurning();
private:
int Color;
int Height;
int Diameter;
bool isLit;
};
its height may have something to to with remaining run time, so you add a function to return its height (which is private):
class Candle{
public:
void lite();
void putOut();
bool isBurning();
bool getHeight();
private:
int Color;
int Height;
int Diameter;
bool isLit;
};
Let the class evolve as you find the need for properties and or member functions (methods).