Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Is it really necessary to use accessor and mutator functions in member functions of a class? That is, instead of directly referencing the member variables of that class, we call a getter to get the value...
I don't see the necessity or reasoning of using accessors or mutators when its within a member function of that same class.
Oh, by the way, these member variables are private.
No, it's not necessary.
It's just a convention, nothing more. Having these kinds of accessor methods -- and using them even in other class methods -- might help make future changes to classes easier to implement, but this is not strictly required.
Well, no, it's not. But it does provide you with a lot of extra possibilities. Especially ones that you'll only realise later.
First of all, you can make them virtual. So any subclass, can implement the setter and the getter in their own way.
Secondly, you can decide later: "oh, whenever that value changes i nead to do something." Just add one line of code to your setter, instead of ctrl-f-ing your entire project or whatever.
And just-in-time updates of course. Imagine there is this value that requires quite a bit of calculation to arrive at. And half the time you don't even nead it. just calculate it in your getter, remember the result for the future, and return it. Now you only calculate it if you actually need it.
So yes, you can make values private, but you have to be really sure that you won't regret it later.
just for fun, have a look at "qt properties".
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
In unversity, my tutor told me always use private variables in class and have a setter and getter function, because it provides better encapsulation. But what is encapsulation? Is there any resons to do so if I know my code is only going to be developed by myself? It's just simpler to use my_obj.var instead of my_obj.set_var(var)!
Encapsulation in the classroom means making an over-engineered 2D point struct. Completely contrived and useless. It does a disservice to the entire concept by teaching it with poor examples.
Encapsulation in the real world is e.g. std::vector which works how you expect and is safe due to not allowing you to tamper with its internals.
In short: no, it's not necessary. It really depends on what you're doing.
In particular, you want encapsulation if your object is handling dynamically-allocated resources directly. So all properly-implemented container types should use encapsulation to prevent you from accidentally breaking it.
But if your type is just a pair of ints or some other raw data, there's really no need.
Specifically, getters and setters should be used if the details of the implementation could potentially change at some later point in the future. E.g. a struct representing a timespan could be represented as seconds:minutes:hours, but could also just be (a lot of) milliseconds. The getters and setters would allow you to turn that into seconds/minutes/etc. without it actually having to be stored that way internally. The operating word here is internal representation.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I get the feeling that this is a duplicate/stupid question, but, despite my best efforts, I don't know what to Google to find anything.
Anyhow, I would like to have a class BigClass that contains another class SmallerClass as a private member variable so that people using BigClasscan't access the public member variables that SmallerClass contains.
However, I also want people to be able to manipulate SmallerClass via it's public methods. I want to be able call bigClassInstance.SmallerClassMethod() without having to make a bunch of methods inside BigClass that just call a homonymous method inside SmallerClass.
Is this possible? If so, how?
Note: I did consider getting BigClass to inherit from SmallerClass, but, this doesn't work as other things that are accessing SmallerClass directly need to manipulate SmallerClass as-is
EDIT:
I'm making a Collider class which is more or less a wrapper class around a Box2D body. I'm working with other people, and I want them to avoid touching the b2Vec2 class whenever possible, in favour of a custom vector class that we're using. With the Collider doing conversions between b2Vec2s and our vectors to maintain consistency.
I didn't make this vague to be annoying, I was just trying to generalise it so that I didn't get Box2D only answers and not be able to apply what I learned to a different problem
You're pretty much going to be limited to one of the following:
write a getter in BigClass that returns a reference to SmallClass (and call methods via that reference).
write small inline methods in BigClass that thunk the call into SmallClass (probably the simplest and best solution).
Use inheritance (which may or maynot be a good idea, depending on scenario)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm making a calendar application in c++ and I'm making a great number of overloaded constructors for the appointment class depending on the information provided(e.g. if i have a start time for the event but no end time, and a location, but no attached contacts)
class Appointment {
public:
//overloaded Constructors
Appointment();
Appointment(Date);
Appointment(Date,Date);
Appointment(Date,Date,std::string);
Appointment(Date,Date,std::string,std::string);
Appointment(Date,Date,std::string,std::string,Contact);
etc. etc. Is there a better way to do this?
You could either:
Create the object (a valid one) and set its properties afterwards via interface setters (since it seems an object can have a variable number of properties this seems like a good choice)
Use default parameters, e.g.
Appointment(Date=getDefaultDate(),
Date=getDefaultDate(),
std::string=getDefaultString(),
std::string=getDefaultString(),
Contact=getDefaultContact());
It really boils down to how you prefer to handle and initialize your objects.
An important sidenote: in large production codebases default parameters is a C++ feature often frowned upon because it might hinder readability and/or render debugging more difficult in particular scenarios (especially when something unwanted goes on and you didn't consider a default parameter being chosen, default parameters are specified on the declaration and that might also "hides" a potential problem from the developers)
This is totally unnecessary. As pointed out Macro A , you can default construct the object and afterwards you can use setters for them.
One more thing when designing a software you should keep in mind the rule of complete and minimal i.e you should provide all facilities in a class avoiding duplication/redundancy.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Many times I hear "Singleton is a bad practice, static methods are bad practice" all I can see for reason is "hard to test".
But I do think sometimes its really good if an operation can be done without instantiate a class.
EDIT: just because of testing, anyone can find out that "private methods are bad too, they cant be tested" for example
It is a question about semantics and expressing intent.
A static method is not inherently bad, apart from that it is hard to test. The bad part is confusing other programmers by using static methods just to avoid creating new instances.
If the method relates to the class itself and not to individual instances (Like a factory method for example), then by all means use a static one. But if the method semantically belongs to an individual instance, then use a non static method.
Static methods are generally frowned upon for much the same reason as global variables, in addition to testing issues:
Static methods do not relate to a specific class instance so will not always be thread safe.
Systems with lots of statics methods often do not scale well.
Confusion due to the mixture between calling static methods of a class and members of an instance of a class can lead to maintenance issues.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
My intuition and practice for a long time has been to avoid out params if at all possible. I believe that a function should have one logical purpose and that usually implies one return type (not returning multiple things). Sometimes, returning multiple things is desirable (f.e. std::map::insert). I know this can be done as a pair/tuple or as output params; the argument of which of those to use is less important to me.
What are the conceptual, design, or performance reasons to prefer either output parameters or return values?
You're right, out parameters are not really needed as RVO makes returning by value feasible, even with large types. And having to return multiple things is either a code smell, or can be sensibly packed in a structure.
I'd say the only remaining reason, and it's a biggie, is consistency. If the class already has tens of methods returning by parameter, stick to it (unless you have the liberty to refactor the darn thing :).
Depending on the context, a third alternative might be to pass a callback. The callback might have multiple methods if the called function "produces" multiple values.
Though a function that takes a callback argument doesn't really fit the definition of a "function", neither does a function that returns multiple values, IMO.