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)
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 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 6 years ago.
Improve this question
I have a event based communication system, and this is the simplifed version of it:
class A: contains elements derived from class B
class B: has a pointer to its owner A
So when a B wants to communicate with other B-s, it calls A's Broadcast() method:
m_owner->Broadcast();
But I was wondering:
Should I make a protected Broadcast() method for B, which is just this:
m_owner->Broadcast();
Pros:
Instead of m_owner->Broadcast() I can write just Broadcast()
this makes the code cleaner.
Cons:
There will be +1 function calling in the procedure.
But this can be avoided by making the method inline
Is this a good practice? Why yes and why not?
In a situation that you have described, it probably indeed does not make much difference.
But in future you may find that you will need to add extra code to each place where Broadcast is called, for example logging or mutex locking. In this case, a separate function will be really useful.
Also you mention that you have classes derived from B. If this is a derived class that calls m_owner->Broadcast(), and m_owner is a base class field, then this is not a good pattern. Derived classes should better access parent's protected functions, not directly data members.
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".
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 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 9 years ago.
Improve this question
I know that "public" let the programmer to have access to members, attributes or other classes and "private" don't let access.
But i wanted to know, how does it actually work during the compilation (g++) ?
I badly explain my question.
I know what will be the effect, i just wanted more information about what the compiler will do, which action to permit public or private access.
When you declare (or define) an object, the compiler creates some sort of internal record containing the attributes of that object. For a C++ compiler, one of those attributes will describe the accessibility of a member object. Then, when the compiler encounters code that attempts to access a member, it checks that identity of the code (part of class/part of derived class/neither) against the accessibility attribute to determine whether the access is allowed.
It's impossible to go into much more detail than that though, because the details will vary between compilers.
If you want to get into a really detailed explanation specifically for g++, that's going to get difficult and ugly. The problem is that the code for the g++ AST is (or at least originally was) written in C, but the nodes in the tree are basically polymorphic. To manage that, they have a (fairly large) set of macros to simulate something similar to a dynamic_cast in C++. Each type of node gets assigned an ID, so the macro checks that the node contains the correct ID to signify the type you're trying to access, and gives you access to the data if it's the correct type.
Among those macros are a number of predicate macros that will let you query whether a particular node has some particular property. It's been long enough since I've looked that I can't guarantee it, but if memory serves one of those will let you query the accessibility of a name.