On Thursday, 16 January 2014 at 18:23:16 UTC, Gary Willoughby
wrote:
On Thursday, 16 January 2014 at 17:45:40 UTC, Boyd wrote:
I think I misrepresented my case by mucking up the example. I
don't care about any individual use case. Ignore it. What I'm
looking for is a way to represent this:
class AThing
{
public void DoSomethingAnyoneCanDo();
public_ish void DoSomethingThatRequiresExpertise();
}
The first method in the class, is something you want to expose
to any user. The second is meant for the guy who wants access
to the more advanced stuff, where you have to know what you
are doing. Inheriting from the class is not an option, or at
least unwanted.
Basically I need the 'package' attribute, but for modules
outside the package, even modules I have no control over, or
know anything about.
Am I really the only who ever found the need for such a thing?
Because I see situations where this could be pretty damn
handy, all the time.
By your example i'm getting the impression you want a standard
interface for users of your class but want advanced behaviour
of the same interface for other users while avoiding
inheritance? If this is the case, your answer is delegation[1].
class A
{
private Delegate delegateObject;
public void setDelegate(Delegate delegateObject)
{
this.delegateObject = delegateObject;
}
public value doSomethingAnyoneCanDo()
{
if (this.delegateObject)
{
return
this.delegateObject.doSomethingThatRequiresExpertise();
}
// Do something anyone can do.
}
}
[1]: http://en.wikipedia.org/wiki/Delegation_pattern
P.S. Don't confuse this with the D 'delegate' type.
No, I'm talking about two different functions with different
functionalities.
The desktop PC is probably a good analogy. The normal user just
turns it on and off. Others might open up the case, change the
CPU multiplier, add some memory, maybe turn down the fans so they
make less noise.
class DesktopPC
{
public void turnOn();
public void turnOff();
expertMode void setCpuMultiplier(int value);
}
