CODEWITHSUNDEEP
design-patterns
Jonah
Jonah

Reputation: 16232

What is this design principle called?

I am looking for the name of a design principle which essentially says, "client code should never have to remember anything special about the way to use an interface."

For example, let's say you had two methods, loginAttempted() -- which checks for posted u/p data -- and loginValid() -- whcih authenticates the u/p. Now say you are always supposed to call loginAttempted() before calling loginValid() -- if you call loginValid() and no u/p was posted, you'll be trying to access undefined variables and get an error. So this example violates the principle in question, since client code has to remember to use loginAttempted() before calling loginValid().

So, what is the name of this design principle?

Upvotes: 1

Views: 140

Answers (3)

radarbob
radarbob

Reputation: 5101

Concrete Example

Is there a way to address this? I mean using delegate to ensure method2 is invoked after method1 or anything similar. –

Spot on. But I'm thinking abstract. Specifics of your overall needs can drive it either way. But we must also add another comment into the mix:

A higher level of abstraction might "fix" this.

Big Picture

  • A public Login() method (for client code), that...
  • Calls LoginAttempted() and LoginValid() in order.
  • Further, these 2 sub-methods are abstract (could be delegates)
  • Thus client code can only call Login() and ...
  • Logging-in implementations can customize how these login functions work and ...
  • their call order is permanent.

BTW, having substitutable methods in an ordered list of method calls is the template design pattern.

This example is in C# (I hope it works!)

public abstract class LogOnBase {

    // add comments here so we know what these are supposed to do
    protected abstract void LogInValid(string, string);
    protected abstract void LogInAttempted (string, string);

    public bool Logon(string userName, string Password) {
        LogInAttempted (userName, Password);
        LogInValid (userName, Password);
    }
}

// concrete implementation
public class LogOnConcrete : LogOnBase {
    protected override void LoginValid (string UName, string PW) {
        // do concrete stuff
    }

    protected override void LogInAttempted (string UName, string PW) {
        // do concrete stuff
    }
}

// Using the LogOn class
public class LogOnExample {
    string whoAmI;
    string passWord;
    LogOnConcrete LogMeIn;

    public LogOnExample (string me, string pw) {
        whoAmI = me;
        passWord = pw;
    }

    public static void Main (string[] args) {
        LogOnExample driver = new LogOnExample (bubba, mySecretPW);
        LogMeIn = new LogOnConcrete();
        LogMeIn.Logon(driver.whoAmI, driver.passWord);
    }
}

Upvotes: 1

Pablo Fernandez
Pablo Fernandez

Reputation: 105238

I can only describe that as a lack of Information Hiding.

The client code must know too much about the other object. In this case, that methodA somehow affects the internals of the object, making it feasible to call methodB afterwards.

I must say that the description you gave rings a (distant) bell, so perhaps there is actually a more formal name for this. But it would definitely be a variant of poor Information Hiding.

Upvotes: 1

Paul Phillips
Paul Phillips

Reputation: 6259

A higher level of abstraction might "fix" this. But this specific pattern you're showing is called sequential coupling, and under most circumstances I would consider it an "anti pattern".

Upvotes: 4

Related Questions