Imagine a class, like this one:

class Foo {
  public:
    Foo(string &name) : name_(name.c_str()) { }
  private:
    char *name_;
}

As you can see, it takes the guts of the string argument passed to the constructor, and stores them internally. In other words, it assumes that the caller is going to manage the lifetime of the string argument so that it lives at least as long as the instance of Foo. Ignore that this might be horribly bad style for a second, and pretend that this is an external class that you want to interface with. What I want to be able to do is this:

Foo f = Foo(string("foo"));

But, of course, that will totally crash. So, I’d like to write a wrapper class, that looks like this:

class FooWrapper : public Foo {
  public:
    FooWrapper(string &name) :
        Foo(make_a_copy(name, name_copy_)) { } 

    string &make_a_copy(string &src, string &dest) {
        dest = src;
        return dest;
    }

  private:
    string name_copy_;
}

But here’s the problem: The code in make_a_copy() crashes because the guts of the string representation stored in name_copy_ is total garbage and not initialized to a reasonable state yet. I could create a factory function and add some yucky methods to FooWrapper, but I’d really rather not. Is there an easier way to accomplish this “copy on construct” behavior?

“The boy put the box in the bag.”

Just to refresh your grade school English (which I had to do as well), take a brief look at the sentence diagramming article on wikipedia. Our sentence above boils down to:

Subject: “The boy”
Predicate & Direct object: “put the box”
Indirect object: “in the bag”

How would you represent that in code? Think about it for a second before continuing. So, here are the possibilities of how this could be written with a single method call:

// Subject-Oriented programming:
// "The boy put the box in the bag"
boy.PutIn(box, bag);

// Direct-object oriented programming:
// "The box was put in the bag by the boy"
box.PutIn(bag, boy);

// Indirect-object oriented programming:
// "The bag, to which was added a box, was done by the boy."  OR
// "A bag now has a box that was put there by the boy."
bag.AddTo(box, boy);

So, which is correct via the principles of OOP? What’s the correct place for the method that does the work? Is it on the Subject of the sentence? The Direct Object? Were you taught how to design this? (i.e. in school?)

In practice, method placement is one of the biggest factors in how maintainable & testable your code is, and code is rarely as simple as what I’ve shown above. How do you figure out where the right place for your methods are?

One code base where this was thought about a lot was in Python’s handling of string & list methods. The split() and join() methods in Python are both on the string type. In other words: The list type is rigid in that its methods contain no string-manipulation. This seems good at first until you read the code:

s = "Hello, world"
# Split the string into a list of "Hello" and "world":
l = s.split(',')
# Now, take that resulting list, and join it back together:
j = ','.join(l)

Wow, that last line looks weird! What’s going on there? We’re creating a temporary string “,” and then calling the join() method! Weird! For that last line, I would have much preferred to write:

j = l.join(',')

To be symmetric with the original splitting code, but to write things that way would place a string generating method “join()” on the list class, which also seems wrong.

Previously, I wrote a program that, given a set like {1,5,10,25}, counted the number of coins needed to make every possible value between 1 and 99 cents. I thought that number would be a pretty good indication of how good the set of values was. The best set for 4 coins was a tie between {1, 5, 18, 29} and {1, 5, 18, 25}.

As I discussed this solution with my friends (long ago) they all mentioned that this wasn’t a very realistic or good measure of how well a set of values performs in the real world. It was suggested that a better metric would be to model real-world transactions, and the number of coins needed.

So, I set off to write a new program. The algorithm would model a single buyer and a number of ‘purchases’ between 0 and 99 cents. Then, I could calculate the average number of coins in the virtual ‘coin pocket’. This average pocket size would be my measure for the ‘best’ set of coin values. The pocket would contain an infinite number of dollar bills, so it never runs out of money, and the bills aren’t counted as ‘coinage’.

But, an interesting question came into play: When making a purchase, the program needs to decide how much to pay for the item, given the contents of the pocket. I started off by implementing a fairly naive algorithm that ended up preferring to use large coins. After looking at the results, I found that the pocket was accumulating as many as 18 pennies before spending them. Although this might be how I personally work, it didn’t seem to be how most people would do it, and it didn’t seem like a good model for the program. So, I pose the question to you, the reader!

If you’ve got 4 pennies and a bunch of dollar bills, do you usually put down pennies to ’round up’ your change? For example, would you pay $1.03 for an item that cost $0.38?

Would you put down extra nickels and dimes to ’round up’ to dimes and quarters? How often? For example, would you pay $1.08 or for an item that cost $0.38 to get back $0.70? This case is particularly interesting because you give up 4 coins (3 pennies and a nickel) to get back 4 higher valued coins (2 quarters and 2 dimes). There’s no reduction in the coin count, but it ‘feels right’ to get higher valued coins back.

How about $1.13 to pay for $0.38? In this case, you would get back exactly $0.75. What if the $0.13 was made up of 13 pennies? Would you still do it?

How about paying $1.63 for $0.88 to get back exactly $0.75? What if the $1.63 were made up of an odd assortment of coins, like 5 quarters, 2 dimes, 2 nickels and 8 pennies? Would you still do it?

At some point (like in the previous example) we start to trade off our own time needed to add and compose our purchase amount for the convenience of just ending the transaction. I think we also consider the cashier’s time and patience, since they may not tolerate waiting as we ponder and compose the ‘perfect’ amount. Not to mention the other people in line behind us!

I think the solution here is going to be a rule-based system, with things like:

If you have enough pennies to round up to the nearest $0.05, then do it.
If you have enough dimes & nickels to round up to the nearest $0.25, then do it.
Don’t overpay for the item by more than $0.50.
Don’t give the cashier more than N coins. (whats N?)

I’ve started to code up some of this stuff in C++, but I’m kind of stymied by trying to come up with a good generalized solution to this problem, especially since the rules conflict and overlap. (And note that any solution has to work for arbitrary values of coins, like {1,4,12,24})

How would you go about tackling this problem?

value = *pointer;

Note how there’s not a space after the asterisk. Also note how the type of “value” and the type of “*pointer” are the same.

Thus, when you declare these variables, you should do it like this:

Type value;
Type *pointer;

value = *pointer;

Why would you ever want to put the asterisk next to the type name? Why would that ever make sense? I just don’t get it!