Java – What design pattern for changing interface

There is no reason why this should be forbidden. The only point of an interface is to ensure that a method with particular signature exists in each implementing class. This is satisfied by any implementing class even if the condition is posed twice.

Granted, when you write an interface you presumably expect a certain meaning for the action of invoking the method, and presumably you document it above the declaration in the interface, but that is not the concern of the compiler. It cannot check whether the implementing class does the right thing, only whether it copies the signature exactly. Asking "Why doesn't the compiler forbid one method to satisfy two interface declarations?" boils down to "why doesn't the compiler prevent me from implementing the wrong semantics when I implement an interface?", and the answer to that question is much easier to see: because it can't! (If the compiler were able to judge your method implementation and forbid it if it contained a bug, then we wouldn't need programmers in the first place, we'd need only the specifications and the compiler.)

Obviously we would like it if implementing an interface guaranteed that the implementing class does the right thing, but that's not something that interfaces can do for you. In fact, I'd argue that it would be a bad thing to add a feature to the compiler that might give the impression that it is!

Here are common design patterns to handle these scenarios.

Set up a base class. Child and parent will inherit from base. Base class should do the following:

1. Have a .Status property (read-only) that tracks if an object is {unchanged, new, updated, deleted} The status is set during {constructor, .delete() method, each Property's setter}. You will need a factory method to generate an object instance with a status of "unchanged" or a method to mark itself as "unchanged".
   btw. This approach makes an object more "atomic" because it is self-contained and it keeps track of its own changes. This is also an example of why people use Properties (getters/setters) instead of public vars.

2. A commonly used pseudo locking mechanism is to use a combination of .LastModifiedDateTime (read only) and .LastModifier (read-only) columns on each DB table (non code-table/static-table). These are also set in the constructor/factory method. On Update/Save, compare the current LastModifiedDateTime & LastModifier to the DB. If they don't match then reject this change.

#1 is similar to the way many ORMs maintain state (handle changes). #2 is often referred-to as a "soft locking mechanism".