Encapsulation and invariants

Discussion in 'C++' started by bluekite2000@gmail.com, Jul 28, 2005.

  1. Guest

    What does "invariants" mean in this sentence "Public data is bad if a
    class models an abstraction and must therefore maintain invariants" ??
    An example is appreciated.
     
    , Jul 28, 2005
    #1
    1. Advertising

  2. wrote:
    > What does "invariants" mean in this sentence "Public data is bad if a
    > class models an abstraction and must therefore maintain invariants" ??
    > An example is appreciated.


    An invariant is something that doesn't change. Perhaps what the author
    of that phrase meant was that if the class is an abstraction, its data
    shouldn't be accessible (changeable) through an object (or a pointer)
    of that class itself, only through the interface to that class. That
    would give any implementation a way to know when the invariants are to
    be changed and maintain data integrity.

    V
     
    Victor Bazarov, Jul 28, 2005
    #2
    1. Advertising

  3. Alan Johnson Guest

    wrote:
    > What does "invariants" mean in this sentence "Public data is bad if a
    > class models an abstraction and must therefore maintain invariants" ??
    > An example is appreciated.
    >


    Let's say I am writing a class that maintains a list of some objects,
    and I determine that it would be useful for the people using my class to
    be able to determine the number of items in the list. So I might have a
    class that looks like this:

    class AwesomeList
    {
    unsigned count ;
    public :
    unsigned get_count() { return count ; }

    // Some more stuff to actually make the list work.
    } ;

    Now, obviously, I want the value returned by get_count() to always be
    the number of objects in the list. That is an example of what we call
    an invariant. Specifically, what is never changing is the truth of the
    statement "get_count() returns the number of objects in the list".

    As long as all the methods I write for my class properly update count,
    then my invariant will hold. But consider if I made count public --
    then someone could change the value of count to whatever they felt like,
    and it may no longer be true that get_count returns the number of
    objects in the list.

    Invariant just means a condition that is always true. A slightly more
    complicated example might be a binary search tree, where you have the
    invariant that at every node, all child nodes to the right have a
    greater value and all child nodes to the left have a lesser value.

    What the quote you gave is trying to say is that making your data public
    is bad because it lets people muck around with the data and change
    conditions that the class depends upon to be true.

    -Alan
     
    Alan Johnson, Jul 29, 2005
    #3
  4. Puppet_Sock Guest

    wrote:
    > What does "invariants" mean in this sentence "Public data is bad if a
    > class models an abstraction and must therefore maintain invariants" ??
    > An example is appreciated.


    In addition to what others have said (which was all great
    as far as I can see) an invariant is a condition that an
    object must satisy to be valid. The invariant should be a
    characteristic of the abstraction, or a property of the
    implementation.

    An invariant does not have to be true while an object
    is actually performing one of its functions. As for
    example, while an object is actually running its own
    constructor, the invariant does not have to be true
    until the ctor is finished and about to exit.

    Consider a class that modeled a supersonic jet fighter/bomber
    aircraft. One thing you might like to do in the spec of the
    craft would be to prevent the accidental dropping of any
    explosives while the plane is on the runway. So, you might
    include a rule (very simple version follows):

    - While the landing gear is extended, the weapons cannot
    be fired or released.
    - Attempts to do so will produce a warning indicator on
    the pilot's information display.

    So, the program that runs the aircraft will keep track of
    the ability to use weapons or bombs. And it will keep track
    of where the landing gear is. And it will keep the invariant
    that when the landing gear is extended, the bombs and weapons
    will not work. And it will also keep track of attempts to
    fire the weapons, and tell the pilot why it does not work if
    he tries to fire with the landing gear extended.

    So, one invariant might be (in sloppy code form):

    ((extended landing gear) && (weapons can fire)) == false

    At any time the code checks, it must be the case that
    not both of extended landing gear and weapons can fire
    are true. Note that the invariant does not have to be
    true while the gear is actually being extended or
    retracted. The code might extend the gear, killing time
    somehow while it waits for the gear to move, then set
    the "weapons can fire" flag to false, then return.

    Another might be:

    (extended landing gear) && (pilot tries to shoot) ==
    (explanatory warning on display)

    That is, whenever the gear is extended and the pilot tries
    to shoot there must be a warning on the display. That way
    the pilot will get a smackdown if he tries to shoot the
    conning tower off the aircraft carrier.

    Now, why would it be bad to let these data be public?
    Suppose some other part of the code knew about the
    "weapons can fire" flag. And suppose the pilot found
    that by, for example, bouncing the gear up and down
    or cycling the bomb bay door or something, he could
    activate the weapons even with the gear extended.
    That other function might set the "weapons can fire"
    flag to true, even though the gear was still extended.
    Bozo-the-pilot might wind up dropping his bombs while
    he was sitting on the deck of an aircraft carrier.
    This would be bad.

    However, it is important to realize that any such situation
    would be a bug in the code. In other words, making the data
    private helps prevent bugs getting into the code by making
    the maintenance coder unable to get at the stuff that might
    break and screw things up.

    Here is a much more mundane example: Cosider a code to
    describe the wiring behind the walls in a house. An
    invariant might be:

    - Between one connection box to another, the wires are all
    insulated and can't make connections.

    If you let people get at the wires at any other place than
    a connection box, then they can pull out their jack knife,
    strip off some insulation, and solder in their desk lamp
    at any old place. This is known as "how the fire started."
    Keeping those electrical wires hidden in the walls helps
    keep snoopy-britches from changing things.
    Socks
     
    Puppet_Sock, Jul 29, 2005
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Wayne Berke
    Replies:
    0
    Views:
    402
    Wayne Berke
    Sep 19, 2003
  2. Replies:
    1
    Views:
    10,543
    kj12345
    Mar 1, 2005
  3. Scott Meyers
    Replies:
    51
    Views:
    4,427
    Chris Cochran
    Nov 20, 2010
  4. Anand Hariharan
    Replies:
    2
    Views:
    407
    Anand Hariharan
    Aug 30, 2012
  5. Replies:
    5
    Views:
    189
    Mark Janssen
    Feb 15, 2013
Loading...

Share This Page