simple class

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

  1. nvangogh

    Stefan Ram Guest

    Richard Damon <> writes:
    >If we started with a
    >typedef double MoneyType;
    >at the beginning of the header, and getBalance() defined to return a
    >MoneyType, then if the client used the MoneyType also, then no change in
    >client code might be needed.


    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

    "Jorgen Grahn" wrote:

    <WRT good introductory samples>

    > All that's needed here is an example where there's a relationship
    > between the members. Stroustrup picked (in TC++PL) a Date class with
    > year, month and day-of-month. Then you eventually want to prevent
    > things like the 31th of February year 0, and there's suddenly a real
    > reason to have more than just a boring struct.


    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. On 2014-05-11 09:47, Vir Campestris wrote:
    >
    > One of the nice things about accessors, not just publicising the data,
    > is that you are hiding the implementation.
    >
    > Imagine that I've decided to compress the data. Everyone whose name is
    > Wong will be described by having an ID of 1, everybody whose name is
    > Smith by 2, and so on.
    >
    > If you've publicised the data you can't do this. If you've publicised
    > a method returning a const reference to the string you can. And
    > there's a different method for changing the name, which is going to do
    > clever stuff to make sure that Miss Wong's bank accounts are
    > associated with the new Mrs Smith. And a thousand other things...


    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
     
    Seungbeom Kim, May 11, 2014
    #23
  4. nvangogh

    Dombo Guest

    Op 11-May-14 20:18, Stefan Ram schreef:
    > Paavo Helde <> writes:
    >> Err, no. If the ultimate goal is to keep interfaces fixed, then
    >> getBalance() would still return double for back-compatibility (and marked
    >> deprecated in the documentation and/or by the relevant compiler-specific
    >> extensions) and there would be a new function getBalanceEx() returning a
    >> fixed decimal.

    >
    > But the effect is the same: all clients that want to benefit
    > from the new implementation have to be changed. I used to
    > believe that the promise of encapsulation was that the
    > implementation can be changed without the clients having to
    > be changed.


    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

    Dombo <> writes:
    >Op 11-May-14 20:18, Stefan Ram schreef:
    >>Paavo Helde <> writes:
    >>>Err, no. If the ultimate goal is to keep interfaces fixed, then
    >>>getBalance() would still return double for back-compatibility (and marked
    >>>deprecated in the documentation and/or by the relevant compiler-specific
    >>>extensions) and there would be a new function getBalanceEx() returning a
    >>>fixed decimal.

    >>But the effect is the same: all clients that want to benefit
    >>from the new implementation have to be changed. I used to
    >>believe that the promise of encapsulation was that the
    >>implementation can be changed without the clients having to
    >>be changed.

    >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.


    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

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.
Similar Threads
  1. cyril
    Replies:
    2
    Views:
    4,649
    cyril
    Aug 25, 2004
  2. Loic
    Replies:
    2
    Views:
    747
    Johan Poppe
    Nov 26, 2004
  3. Purush
    Replies:
    4
    Views:
    3,347
    Purush Rudrakshala
    Apr 13, 2005
  4. E11
    Replies:
    1
    Views:
    6,092
    Thomas Weidenfeller
    Oct 12, 2005
  5. christopher diggins
    Replies:
    16
    Views:
    1,179
    Pete Becker
    May 4, 2005
  6. Joseph Turian
    Replies:
    5
    Views:
    1,001
  7. Christian Maier
    Replies:
    3
    Views:
    696
    John Harrison
    Feb 15, 2007
  8. chandan
    Replies:
    2
    Views:
    985
    chandan
    Dec 3, 2007
Loading...