simple class

Discussion in 'C++' started by nvangogh, May 9, 2014.

  1. nvangogh

    Stefan Ram Guest

    In the client, one can have case A (old solution):

    double b = account.getBalance();

    or case B (your new suggestion):

    MoneyType b = account.getBalance();

    . In case A, the client's author can then write

    ::std:cout << 0.05 * b;

    . In case B, the client needs more support from the
    implementation to be able to do this. The client's author is
    not supposed to know that »MoneyType« is just »double«.
    Therefore, he cannot write:

    ::std:cout << 0.05 * b;

    , because he does not know whether MoneyType supports those
    operations and what their semantics is. But usually the
    client might need to calculated something with the balance
    or to serialize it to a human-readable stream. So he needs
    more support from the library than just the statement
    »MoneyType is an opaque type that you do not need to know
    anything about.«

    Possibly, MoneyType might grow to become a new type
    implemented by a class. Well, then this class better not
    have a »toDouble()« method, because otherwise the clients
    might use it and then the same problem will arise anew.
     
    Stefan Ram, May 11, 2014
    #21
    1. Advertisements

  2. nvangogh

    Osmium Guest

    :

    On Page 236! Wow. What a buildup to the first introductory class. I have
    always used the book as a reference, it's got post-its out the kazoo. But I
    never actually read it as a student would do so I never saw that example.
    K&R use dates a lot too - I have actually read it, many years ago. I think
    the moral is "Dates are good."
     
    Osmium, May 11, 2014
    #22
    1. Advertisements

  3. What you're talking about is on a different level of abstraction;
    if you want such a dictionary-based storage of strings, you can
    employ a DictString class which holds an ID or an index into a
    static dictionary member, but the Person type should still be:

    struct Person
    {
    DictString name;
    std::string address; // or any other sophicasted class
    // instead of std::string
    };

    and there's no need to clutter the Person type with get_name()
    and get_address() functions.
     
    Seungbeom Kim, May 11, 2014
    #23
  4. nvangogh

    Dombo Guest

    Op 11-May-14 20:18, Stefan Ram schreef:
    Encapsulation won't help in case the interface itself is broken, like in
    this example. And since the interface is broken, so are the client using
    it, hence changing the client is unavoidable. Only if the interface
    isn't broken you can change the implementation without having the change
    the clients.
     
    Dombo, May 12, 2014
    #24
  5. nvangogh

    Stefan Ram Guest

    Can we derive any general lessons for interface design from
    that, rules that might have helped to impede the offending
    interface right from the start?
     
    Stefan Ram, May 12, 2014
    #25
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.