Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Liskov substitution principle broken with inheritance #137

Open
Wadeck opened this issue Mar 16, 2018 · 0 comments
Open

Liskov substitution principle broken with inheritance #137

Wadeck opened this issue Mar 16, 2018 · 0 comments

Comments

@Wadeck
Copy link
Contributor

Wadeck commented Mar 16, 2018

Definition of Liskov's principle: If S is a subtype of T, then we can replace T by S and all the properties are still true.

I dunno if it's a desired feature or a unfortunate side-effect.

If we consider those two classes:

class A {
   @WebMethod(name = "fromA")
   public void entryPoint(){...}
}

and

class B extends A {
   @Override
   @WebMethod(name = "fromB")
   public void entryPoint(){...}
}

and they are both "gettable" from the root object.

My initial expectation was to have valid URLs: /a/fromA/, /b/fromB/ and /b/fromA/. But actually the last one is not considered.

  1. We can consider it's the expected behavior, meaning you have full control on your class. As you can provide multiple name in the annotation, there is no problem.
    1. Problem, in case the class A comes from a third party and they add a new name, as a library user you are not notified about that change and your class B will not be Liskov-compliant.
    2. Imagine you have an endpoint that propose a list of A. But inside that list, one element is a B. If you consider reaching the URL: /list/0/fromA/, if you fall on the B element, you get a 404 while a normal response was expected.
  2. As an alternative to keep the full control, we can process the annotation of all the parent classes and add a new annotation that explicitely tells Stapler
    1. either we want to remove one name from parents (to have possibility to rename URL)
    2. or avoid completely going further in the hierarchy (to avoid undesired third-party change)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant