Let’s say I have ThingImpl and IThing. The former is an implementation of the latter, which is an interface.
IThing has 1 method: do(arg1)
Is it considered a hack/bad practice to add a method in addition to do()?
Example: do(arg1, arg2)
Assuming that do is still an accurate name (and consistent with the other do method), I don’t see any problem with doing this. In fact, it’s a pretty common pattern.
2
As Oleksi mentioned, it is a common pattern. But make sure it is not public. If you want to make it public, better add to Interface itself.
7
I think you may not be fully understanding what the purpose is behind programming to Interfaces. The reason to do it is so that any client code can get an object of type IThing and know what to do with it. So there would be no way for the overloaded method to ever be called by a client whose entire knowledge of the ThingImpl is that it is an IThing.
That said, I frequently consider my Application as a system similar to ordering something from Amazon.com. I order something and an IThing is made in the Factory. The wiring code in the application is quite happy with an IThing, as the UPS truck is with a box. However, when the box get to its destination, I care again that what’s in my box is exactly what I ordered (so I’ll check the inventory to make sure the content of the box is specifically what I’m expecting). More literally, the endpoint code will check the implementation type of the IThing before attempting to use it.
It sounds like your code actually is the Factory. In cases like this, I’ll actually just create two Factories, one that knows how to set the parameter to true, and the other which knows how to set it to false. The Factories will be stored in some sort of hash and called up based on the specifics of whatever I’m creating (for example, I might have a registry of Factories that create Question data objects based on information I get from an XML file, and I’ll pull a particular Factory out of the hash based on the question type).
2