IMHO The approach you are describing sounds similar to the SPA applications made with any frontend tech (svelte, vue, react) with a SSR implementation. If we can learn anything that is dom manipulation if done in correct way is certainly faster than loading a web page. What you are trying to achieve here is combination of lazy loading of components and ...
The solution we want here is this: we need to add a method to the old classes which converts from them to the new classes.
This works fine in an OOP system in which new methods can be easily introduced over existing classes.
Here is one I made myself, for TXR Lisp:
;; We have some old classes
(defstruct old-a ()
(defstruct old-b ()
;; We ...
You're assuming that sites replace parts of the DOM because it is faster. It is not really. Instead:
replacing the DOM is often perceived as faster
replacing the DOM allows us to maintain state across pages
By maintaining the old layout, maybe showing a loading animation, and then replacing the page contents in one go, the website can avoid the displaying ...
It's a technical foul, but mostly an excusable one.
While this is ostensibly doing the exact thing that LSP examples tend to demonstrate, as you are building a mapper here, needing to know concrete types is one of the few cases where upcasting is actually a reasonably well-justified approach.
That being said, things can be rejigged a bit here to further ...
Rather than playing lawyers over whether this violates the Liskov Substitution principle, let's look at what this interface could actually be used for.
In the comments you give this example of using the interface in a service:
private OldToNewConverterInterface $converter;
public function __construct(OldToNewConverterInterface $...
One could defend that this design is LSP compliant thanks to the exceptions foreseen in the interface definition. However, this theoretical analysis is misleading since it is based on a useless contract that does not correspond to the expectations. In reality, there your scenario allows no subsituability with a meaningful result in general.
If you work with vendor code, you don't RY because it wasn't you who wrote the original code :-) So don't make your life harder than it needs to be.
Regarding the subtractive extension vs. keeping a modified version: both variants are possible, and as the vendor apparently didn't provide a preferred method of doing this in customer-specific extensions, it's ...
I would suggest considering ORM classes as only having responsibility for representing the shape/structure of underlying database records (from tables, but potentially also views/queries/stored procs/etc) rather than trying to include any behaviour in those classes.
Database persistence and Object-Orientation seek radically different goals and therefore ...
It seems like a super bad idea, but include does do this exact thing.
I would say its a very "procedural" way of thinking, you're assembling code like it's a single page which is going to run from top to bottom. Perhaps that kind of approach is how you ended up with your current problem?
Obviously its impossible to know without seeing the actual ...
Is there no pattern, way of architecturing my objects to escape this?
The good news is, there is. The slightly worse news is that it requires you to change how you view your types/classes interfaces and how they represent the logic you need them to perform.
The main problem you're battling with here is that your approach is something that is not really how ...