Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Some of the potential problems with returning a pointer or reference to a private member:</p> <ul> <li>As you mention, encapsulation is breached. You have given access directly to the member, despite the fact it is private.</li> <li>If the <code>Text</code> class keeps some invariants over its <code>TextProperties</code> member, those may be invalidated by modifying the object from outside the class.</li> <li>The client code must be aware that the reference is only valid while the <code>Text</code> object that returned it is still alive.</li> </ul> <p>As your friend says, these would all be true if you just make the member public. However, maybe you want to do some extra work around simply returning the member (such as maintaining those invariants).</p> <p>Sometimes these are necessary issues to deal with if you really want the interface as you described. For an example of this in practice, take a look at <a href="http://en.cppreference.com/w/cpp/container/vector/operator_at" rel="nofollow"><code>std::vector::operator[]</code></a> - it returns a reference to the element. Note that the semantics of this function and yours are different, however - <code>std::vector</code> is a container, so <code>operator[]</code> is exposing the elements that are contained within (just like using <code>[]</code> on an array would). Instead, you are exposing some state of your <code>Text</code> object.</p> <p>If I had to pick between them, I would always recommend using the reference returning getter over returning a raw pointer (unless its possible for there to be no <code>TextProperties</code>, in which case you'd return <code>nullptr</code> (or use a <code>boost::optional</code>)).</p> <p>If acceptable, however, the safest and cleanest interface is to simply return the member by value and also have a setter that takes it by value. This should be your default approach, but you may not want to do this if copying the object around may be unnecessarily expensive.</p> <p>Just think about the tradeoffs and pick a design that best suits your class. Honestly, I can't see a reason why you wouldn't just get and set by value.</p>
    singulars
    1. This table or related slice is empty.
    1. POGetter vs public member and the possibility to replace the returned object
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USJoseph Mansfield
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COSo you point out that returning a reference is safer than a raw pointer. This is a thing I didn't mention in my question und I agree to that. But my question is more focused on the "encapsulation breach" when returning a reference/pointer and if doing so the difference to a public member. Maybe the question can be shrinked to "Why use getters/setters instead of public member when breaking the encapsulation anyway when returning a reference?". For that point, as far as I understand you, you would bring in the invariants?
      singulars
      1. PO
      1. USOnsokumaru
    2. CO@Onsokumaru See [Classes Should Enforce Invariants](http://www.artima.com/intv/goldilocks3.html). Make members private when you have some invariant to maintain. Other than that, you may as well just make your members public (unless your class interface design can be better expressed with a function, like in the `std::vector` case).
      singulars
      1. PO
      1. USJoseph Mansfield
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload