Question

If I have an interface for a Server like this…

interface IServer
{
    void Login();
    void Post();
    void Get();
}

…where Post and Get don’t work unless you’ve done Login first. Is it a semantic violation of encapsulation, since it makes your use of the interface implicitly dependent on the implementation? How would you fix it?

Answer 1

My idea:

interface IServer 
{
    ISession Authenticate();
}

interface ISession 
{
    IServer Server{get;}
    void Post();
    void Get();
}

Ignore that if you are accessibly of “mud”:

[MUD]

to clarify this: imho you have to think about software design as you
would create a product… do you really want a safe for all your
valueable things where you can push a button “open” instead of FIRST
input the code on it? this is just an analogy for your use-case…

an implementator can just call post and get before he validates…

another widely used approach are access-tokens and the use of it like
here:’

interface IServer{ // returns the required token string
Authenticate(); void Post(string token); void Get(string token);
}

but i think, that’s wrong too…

you can see and maybe call methods, which you are not allowed to
see/call before login… if the implementator just not checks if
“token” is correct, you have a security risk in here…

if you divide the logic into several layers (guest/unauthenticated,
authenticated/session, and (for example) adminsession) you get clean
separation of logic and a lot more semantic usefullness….

I PERSONALLY write code EVER in way, that good framework-builders would write code… it has the be reuseable, even after years, very
easy and clear.

[/MUD]