Re: [PHP] How do I handle covariant parameters and not fall foul of LSP.
[email protected] (Richard Quadling)
| Newsgroups | php.general |
|---|---|
| Message-ID | <CAKUjMCXEXqy=VB8Jjjg8XKdUsc5NsqQTeZcs54+V5e4GH1RYYw@mail.gmail.com> |
On 14 February 2017 at 20:31, David Harkness <[email protected]> wrote: > On Tue, Feb 14, 2017 at 2:20 AM, Richard Quadling <[email protected]> > wrote: > >> If the process method is doing storage related things I don't think is a >> good idea to move it to the Entity hierarchy. >> > > I totally agree. I was just showing a way to avoid violating LSP. > > On Tue, Feb 14, 2017 at 2:20 AM, Richard Quadling <[email protected]> > wrote: > >> I still can't see why an extended BaseEntity is still not a BaseEntity, >> just a more specialised variant. >> > > Because you're changing the contract in PersonEntity::processEntity() from > taking any BaseEntity to accepting only PersonEntity, you cannot substitute > any BaseEntity for it. > > If anyone has some good examples (real world ideally) where LSP is sane >> AND includes inheritance (they seem to be where the conflict lies) then I >> may be able to learn why I'm doing it wrong. >> > > A typical example is multiple cache backend implementations: CacheFile and > CacheMemcache. Swapping between the two requires no changes other than the > initial setup. The user of the cache shouldn't know or care which it has. > > Cheers! > David > That's fine for concrete classes, but abstract classes which cannot be instantiated, therefore cannot be swapped, cannot fall foul of LSP. It is the abstract part that, in my mind, should be making the difference. Obviously, if someone makes an abstract class non-abstract, LSP will kick in, but that is an odd thing to do in a framework. I'm happy to leave this alone as I think I'm not truly seeing the issue with abstract classes and LSP in the way I'm wanting to implement them. I've gone with the proxy approach - which is fine. Thank you all for your comments. Regards, Richard.