Q. How many OOP developers does it take to screw in a lightbulb?

A. None.  As long as the "screw in" method has been defined for
the "lightbulb" object, you need only send it a request.
(You can figure out for yourself how to word *that* request!)

Ok. But should you tell the ligthbulb to "screw itself (into this socket)" or should you tell the socket to "get screwed (by this bulb)"? (in fact this is a serious question :-) )

I would think that the socket should have the responsibility to determine if the lightbulb is the right size for the socket. Hence the lightbulb should be passed to the screw method of the socket object. Let the socket, "screw itself"!

class socket
{
public:
virtual bool screw(lightbulb*) = 0;
};

Now we can have a many kinds of sockets, each with their own screw() method.  We can also can pass screw() different kinds of lightbulbs.

I say it is a big mistake to separate the lightbulb insertion and the test for success.  Someone may try to turn it on in the meantime.

To bring related topic up, once the bulb is screwed in, it is no longer available.  Now that I think of it, here is the deal:

void socket::screw(lightbulb*&) 
{
. screw code

if(... successful screwage...) {
delete lightbulb;
lightbulb=NULL;
}
}

..

lightbulb *pmybulb = new lightbulb(eVoltage110,etc.); 

mysocket->screw(pmybulb);
// now you can check if pmybulb is null to see if successful.

Although this may disagree with some people's styles on separating new and delete.  However, I prefer that to an imperfect object model that results in the same bulb being available for others after having been screwed in already.

Also, the lightbulb constructor should take money as an argument, as there is no such thing as a free bulb :)

If you want to keep the screwed in lightbulb around we obviously don't want to 'delete' it, but we still may want to 'clear' that particular pointer in the method where the pointed to lightbulb is screwed in.

[Quoting:]

: class socket
: {
: public:
:   virtual bool screw(lightbulb*) = 0; : };
: 

A typical (wrong) example of "how do I find the Objects?". Indeed you have three Objects: the socket, the bulb and something capable to screw it in (a robot, a person etc.). Most "Objects" use the same method to screw in a lightbulb, but some may declare their own, so we implement a base class with a public virtual member screw:

class capable_to_screw_in_a_lightbulb {
public:
virtual void screw(socket &s, lightbulb &b) {
b.moveTo(s);
b.screw();
}
};


/* uses standard way to screw in a lightbulb */ class person: public capable_to_screw_in_a_lightbulb {
..
};


/* uses it's own way to screw in a lightbulb */
class microsoftProgrammer:public capable_to_screw_in_a_lightbulb {
public:
virtual void screw(Socket &s, Lightbulb &b) {
throwAway(b);
declareStandard(obscurity);
}
};

[Answering a quote:]

It started as a joke whose "requirements" at the time my code was written involved only a socket and lightbulb.  Whether one uses a controller or not depends on the requirements and overall design of the project.

[Another quoting:]

:    void socket::screw(lightbulb*&) :    { 
:        .. screw code
:      if(... successful screwage...) :      { 
:        delete lightbulb;
:        lightbulb=NULL;
:      }
:    }

That's not such a good idea. Once you've screwed in the bulb, you can no longer check what wattage, colour, etc it was. Surely then, this is an argument for telling the lightbulb to screw itself into the socket - the bulb should record the fact that it is screwed in to a socket (though in the UK, they clip, they don't screw), and refuse subsequent requests for screwing. Though of course, you could then try and screw two bulbs into the same socket...

Perhaps the answer is to provide a "Screwer" object that brings the lightbulb and socket together, and is responsible for updating the state of both.


[..to be continued]