This Forum References:
The video on this topic did not explain why you used your setValue method to call the original setter methods instead of ditching them and just setting the value of _number directly in each setValue method. Is this a best practice? Was it just to show the Open Recursion?
I think this is a great practice, although there are probably many that disagree with me... And that is great...
The reason I like to code this way to to ensure that all my core code is centralized. This example is to simple that it hardly matters, but if you had a program with a setter method that was fairly substantial then it is in your best interest to make sure that it stays in one place. This makes it easier to debug later and if you find a syntax, logic, or any other type of runtime failure then you only need to correct the code in one location. Does this make sense? Let me know...
"Does this make sense? Let me know..."
Yes and no. I can see that setValue() is a rather generic name for a method and if the code in it where complex it might not be immediately clear what is being set or how. If the only line in the generic method is to call a more specific method it will be more clear what is happening by the method name your calling.
I don't see how your centralizing anything though (or keeping code in one place). Either way you have a separate setter method for each of your private members in the implementation.cpp file, only the name of the methods change. If anything its one less jump to one less method when debugging or troubleshooting. That being said I do not have much debugging experience so I cant really speak from experience what makes it easier or not.
Having grandiose delusions of hacking skills in my teens I played with debuggers like SoftICE, IDA Pro, and OllyDBG on binary files over the years but those did not have the benefit of debugging symbols so it did not mater what the programmer named anything.
Lets just say that the SetIntegerValue method contained 25 lines of code. If you make a generic SetValue method that is overloaded to accept an integer then you know that the sme 25 lines must be executed in order to perform the same action, right? You could very easily copy and paste the exact 25 lines into the SetValue integer overloaded method. My point is, if someone finds a "bug" somewhere in those 25 lines they may not know that it must be changed in multiple places, therefore, the bug still exists for code that is using the SetIntegerValue method. The cenrealization is keeping the 25 lines of code isolated to only the SetIntegerValue method. If a bug is found when implementing the SetValue method then the developer will be able to see that it simply calls another method and the fix can be applie there. Does this make anymore sense? See, this example is too simple to demonstrate what I'm saying, so you need to use your imagination a bit
Im still a bit fuzzy on this argument.
If you inherited the code and it used all the separate methods for each datatype and you wanted to improve the interface by adding a overloaded setValue method than it would make since since you would need to leave the setIntValue method in place to support existing code. At that point duplicating the code in setValue would mean you had to fix it in two places.
If the code is new though the only place it would live is in the setValue method and you would still only have one place to fix it. NO?
Are you saying that when your debugging you may only know your in "a" setValue method but it might not be obvious which setValue method your in? If that is the case then I can understand since the problem never will occur in the somewhat ubiquitous setValue method and but will occur in a non overloaded method that is only implemented in one place that you can immediately identify.
That being said there is no need to beat this issue to death. I have accepted a couple of your points and that is good enough reason to just do it that way.
Totally cool. You do it whichever way works best for you.
In this video for the first time you use char instead of char* and I don't quite understand the difference.
Another unclear point is the difference between single vs double quotes - '' vs "".
And in general why C and C++ is designed that char arrays have to be pointers?
Why not create is a regular variable and then access its values using pointers?
Welcome to the WiBit.net forums! Check out our terms and features:
Annoy your friends
Is this something you think someone else would enjoy? Is it not for you, but do you know someone who is down with this type of content? Well share away:
This blog is a reminder that cheating in software development can get you into big trouble. Sometimes developers get really really lazy, OR are pressured to write something using overly simplified data structures. Almost every time this happens you are bitten in the butt! Sometimes the problems show up immediately and other times it may take months or years (especially in integrated systems).
- 1 of 78