Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #9590

Re: Liskov substitution principle

Show all headers | View raw

Chris Angelico <rosuav@gmail.com> writes:

> What if the base class implemented study(), and then LazyStudent
> subclasses Student but makes study() raise NotImpl? Would that break
> things? In a sense, it breaks the whole "this is a student so it
> should act like a student" rule.

That would break the Liskov substitution principle, yes. Anything that
asks for a Student instance should receive an object that can do at
least everything Student can do.

If you want to implement something that can't do some of the things
Student can do, the Liskov substitution principle says you are
implementing some object that does *not* inherit from Student.

This fits nicely with the principle (whose name I'm currently too lazy
to look up) that says you should only use inheritance for “IS-A”
relationships. If LazyStudent can't do everything Student can do, then
it's false to say LazyStudent IS-A Student, so using inheritance for
that would be to state something in code which isn't true.

> Suppose it raised UtterApathyError instead - does that break the LSP?

Probably, yes. Your point is taken though: it's not something that can
be drawn along a bright line.

-- 
 \             “Those are my principles. If you don't like them I have |
  `\                                            others.” —Groucho Marx |
_o__)                                                                  |
Ben Finney

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: list(),tuple() should not place at "Built-in functions" in documentation Inside <fancheyujian@gmail.com> - 2011-07-15 12:53 -0700
  Type checking versus polymorphism (was: list(),tuple() should not place at "Built-in functions" in documentation) Ben Finney <ben+python@benfinney.id.au> - 2011-07-16 09:24 +1000
    Re: Type checking versus polymorphism (was: list(),tuple() should not place at "Built-in functions" in documentation) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-16 12:47 +1000
      Re: Type checking versus polymorphism (was: list(), tuple() should not place at "Built-in functions" in documentation) Chris Rebert <clp2@rebertia.com> - 2011-07-15 22:02 -0700
        Re: Type checking versus polymorphism (was: list(), tuple() should not place at "Built-in functions" in documentation) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-16 16:33 +1000
  Re: list(), tuple() should not place at "Built-in functions" in documentation Chris Angelico <rosuav@gmail.com> - 2011-07-16 09:27 +1000
    Liskov substitution principle (was: list(), tuple() should not place at "Built-in functions" in documentation) Ben Finney <ben+python@benfinney.id.au> - 2011-07-16 10:04 +1000
      Re: Liskov substitution principle (was: list(), tuple() should not place at "Built-in functions" in documentation) Chris Angelico <rosuav@gmail.com> - 2011-07-16 10:17 +1000
        Re: Liskov substitution principle Ben Finney <ben+python@benfinney.id.au> - 2011-07-16 11:47 +1000
  Re: list(),tuple() should not place at "Built-in functions" in documentation Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-16 14:06 +1000

csiph-web