Is there any value in creating a class for some code when there can only be one instance of the class (because it needs to use INT0).
I have the code working without using a class.
A good bit of work will be needed to adapt it to suit the structure of a class.
It doesn't seem to be straightforward to build the ISRs inside a class.
...R
In my opinion if the code is working and does exactly what you want it to do then there won't be much reason to change it. If you want to expand the code and build upon it, then you might get value out of it being a class.
As already said, there is no reason to change if the code is fine where it is.
However, once you become familiar with the features C++ brings to the table, you may be able to see more efficiency in an object based design. Apart from allowing use of object orientated paradigm's, C++ objects offer a vast variety of advanced features like Raii, templates, CRTP, and template meta programming.
Aside from all the good stuff, you pointed out one place where classes are better as a multiple,... ISR's. they need to be global or non-member functions, so you will still need a mechanism to pass it to a member of an instance.
However if you only need one instance, there is actually no need to have any instances... simply mark each class member as static and you enforce a single copy ( all instances, if created use the same data ), also it solves the ISR problem as a static function is a 'non member' function.
Then you access the static class members using the scope operator:
//Non static member access:
MyClass f;
f.foo(); //Will still access foo, even if it is marked static.
//Static member access:
MyClass::foo();
Of course the advantage may seem little, however you can encapsulate features like this, and also reuse common names for identifiers which would otherwise be in the global scope and having to be unique.
Is there any value in creating a class for some code when there can only be one instance of the class (because it needs to use INT0).
Plenty of good reasons. Grouping of functions, private status of internal working data, ability to distinguish between functions which happen to have the same name, but are in different classes or do different things, managing projects with more than one person working on them.
But it isn't compulsory.
Plenty of good reasons. Grouping of functions, private status of internal working data, ability to distinguish between functions which happen to have the same name, but are in different classes or do different things, managing projects with more than one person working on them.
ALL of which can be done just as easy without the use of a class.
Grouping of function, provided by the .c file (you can use .cpp if you wish), its called file scope.
Function with the same name - lots of ways to deal with this in big projects without getting name clashes or needing classes
It's splitting the project into many files which allows you to have more than one person working on a project at a time.
C++ or classes does not added any of the things you claim to C/C++ they where all there BEFORE C++.
Mark
Thanks for the comments - and more will be welcome.
I haven't yet seen any comment that makes me feel there is a useful return for the effort of rewriting my code into a class.
And it seems to me the code will be easier for others to understand (especially less experienced users) if it is not in a class.
I have some more testing to do so I don't need to make a final decision today.
...R
There are many cases where a singleton (a class that can only be instanced once) is useful. While your title is specifically about singletons, the topic suggests that the real question is something other than the thread title.
Think about a hotel class. There can be many instances of the hotel class.
Each instance of the hotel (possibly) has a doorman. There are many instances of the doorman class, but there is, at any given time, only one instance that is active. It is the active instance that responds to interrupts for a specific instance of the hotel class.
The hotel instance needs a mechanism for keeping track of the active instance of the doorman class. The doorman instances need a way of telling the hotel instance that it is a particular doorman instance's turn to be the active instance. The hotel instance needs to inform the active doorman instance that it is off duty (so it stops responding to interrupts) and accept the "Hwy, I'm the active doorman" instruction to change the active doorman instance.
Whether all this is necessary in your code, or not, only you can decide.
Thanks Paul,
Your analogies are very good and help to illustrate the issue nicely. But the doorman example is not appropriate in this case. A better analogy would be the Hotel front desk. Most hotels only have one of them (and I mean the whole thing that can accommodate several staff in a big hotel).
In my case my code needs to use the pin that triggers INT 1 hence each Uno (Hotel) can only have one instance of the code because it has only one pin connected to INT 1. (And I'm too lazy to write and test the code so it can use the more general interrupts).
I do recognize that you could have different routines responding to INT1 at different times (like different doormen on duty). I'm only interested in one individual doorman who may or may not be on duty. If somebody else wants to do something while my doorman is asleep it will be up to them to write the code.
...R
If you want to share your code and give it to other people to work with, then I believe a class is a beautiful construct for this "black box" of code. It presents a very elegant interface to the programmer, and makes the code very easy to understand. And if you have to implement it as a singleton, then so be it, that's why there's a pattern for a singleton class.
If you have it in a class, then a developer simply call methods on it, and refer to it every time, making it very easy and logical, e.g.
FrontDesk.begin()
FrontDesk.process()
FrontDesk.getLastGuest()
FrontDesk.close()
In contrast, if you are just using method names with functions from a library, then you would run into issues like potential duplicate function names, or forgetting what a function name was, or trying to remember where or what the function related to. Imagine you import 5 modular libraries, and just calling their respective function names, without a very good naming standard (implemented by each author of the respective module), you would eventually forget what library each function refer to.
I would prefer a singleton class to a class with purely static members. The small overhead of a factory method is worth the cost IMO and makes it easy for you to cope with future variations in the requirements. There have been so many occasions in the past where a singleton needed to evolve into a class hierarchy or n-gleton that I usually take this as an implicit requirements for maintainability.
A singleton is good for storing data that you need to share with other classes or instances.
I use it as a delegate for all the other classes.
@mistergreen & @PeterH, Both your usage methods are reasons not to use a singleton.
As for maintainability, not likely. Using instances of a static only class means if you have to one day have more than one set of instance data, you remove the static keywords and add a constructor.... Thats it.
If you use a singleton for this, you have to go and replace every usage of it with an instance access rather than accessing through the scope operator.
Singletons can have their uses, but most of the uses described here are worthy of plain straight forward design patterns.
The number of instances should not be an important factor in deciding to create a class. If you are using object oriented design, then it is natural to create a class for each object in your design, regardless of how many of them there will be. The value of creating a class varies with the complexity that will be encapsulated by the class (among other things). If you have many attributes and methods, a class adds a lot of value. Similarly a class with no methods and one attribute is really just a variable.
Also consider that if you create a class, your code can only be used from C++. Maybe that's not a big deal for your purposes.
In quoting this Post I am not ignoring those that followed it, I think my comments here also bear on the others.
TRex:
If you want to share your code and give it to other people to work with, then I believe a class is a beautiful construct for this "black box" of code.
I very much don't want my box to be black. I want people to be able to see and understand what is inside.
If you have it in a class, then a developer simply call methods on it, and refer to it every time, making it very easy and logical, e.g.
FrontDesk.begin()
I don't think classes have a monopoly on that sort of simplicity
In contrast, if you are just using method names with functions from a library, then you would run into issues like potential duplicate function names, or forgetting me wawhat a function nas, or trying to remember where or what the function related to
I agree that using classes gives the programmer some control over function names (the name of the class instance) but classes don't make remembering method names or purposes any easier - that is down to the documentation
I am also conscious that some comments seem to view the issue in terms of wider C++ programming. My project is only relevant to the limited Arduino system, and probably only to the Uno and Atmega 328 and I am strongly inclined towards a minimalist solution for that environment only. (If I was programming for my PC I would be using JRuby which is entirely class based)
Again, thank you all for your comments. They are all food for thought. I hope I will have my projected completed by tomorrow. OK, it will take a bit longer if I decide to convert it to a class.
...R
pYro_65:
@mistergreen & @PeterH, Both your usage methods are reasons not to use a singleton.
I don't understand why you think that.
pYro_65:
@mistergreen & @PeterH, Both your usage methods are reasons not to use a singleton.
It works for me and keep class communication simple and easy soooo, I like it. I learned it from using objective-C, how Apple setup their structure. They have an App delegate, which is a singleton that is the hub for all the other classes.
mistergreen:
, how Apple setup their structure. They have an App delegate, which is a singleton that is the hub for all the other classes.
Apple devices are a tad more complex than an Arduino Uno ???
...R
Robin2:
mistergreen:
, how Apple setup their structure. They have an App delegate, which is a singleton that is the hub for all the other classes.Apple devices are a tad more complex than an Arduino Uno ???
...R
Design patterns care not the device.
mistergreen:
Design patterns care not the device.
Yes dear.
...R