c# - Hierarchies of Visitors modifying the behavior of parent. Is it fine with Liskov? -

there class iuser. has function takes visitor , allows changes public properties.

public iuser {     public permissionmatrix permissions { get; set; }          public void authorizations(iauthmanager manager)     {        manager.setroles(this);     } } 

now, can visited class hierarchies of iauthmanager

public iauthmanager {    public void setroles(iuser user); }  public internalauthmanager : iauthmanager {    public virtual void setroles(iuser user)    {      // sets permissions in user internal security      // according complex logic    } }  public restrictinternalauthmanager : internalauthmanager {    public override void setroles(iuser user)    {      base.setroles(user); // need use complex logic of parent      // reverts few permissions based on conditions    } } 

i want evaluate if class restrictinternalauthmanager violating liskov substitution principle. have been arguing both yes , no,

no : there no check type of iauthmanager.

yes : restrictinternalauthmanager changing post-conditions of internalauthmanager.

can left is, or classes require refactoring? appreciated.

let Φ(x) property provable objects x of type t. Φ(y) should true objects y of type s s subtype of t.

now problem haven't specified behavior of setroles method; if 1 infer "it sets permissions", not changing behavior. if say, "this method in such , such way" , in subclass change it, yes, violate lsp. i.e. if "get() retrieves item" both queue , stack, ok, if "queue.get() retrieves oldest item" , "stack.get() retrieves newest item" different.

the idea behind lsp is, expected behavior doesn't change, example if write tests base class, tests must pass if provide subclass instead.

another important question is: subtyping, or subclassing? if change behavior of superclass, need make changes in subclass? merely reusing implementation in superclass out of convenience? if so, violation.

think happen if needed yet manager adds 1 more thing; out of hand quickly. if unsure whether inherit, better use decomposition instead.