Designing two similar classes that share many (but not all) properties and methods?

Question

.NET

The situation is this.
There are two printers from different manufacturers. We want the top level to know nothing about them and just use the class with a single set of methods and properties.
I start highlighting the interface.

public interface IPrinterProvider {
        bool Connect(string comPort);
        bool IsConnected();
    }

But it turns out that one printer needs to send a password to perform many operations, while the other does not.
How to be?
And further.
As I understand it, I should get one or a couple of interfaces and a couple of heirs here.
And how will the caller work?
Do I need to create a separate class for it, which, in principle, may not implement any interfaces? For example:

public class CommonPrinterProvider {
        private IPrinterProvider printerProvider;
        public CommonPrinterProvider(IPrinterProvider printerProvider) {
            this.printerProvider= printerProvider;
        }
    }

There are two questions in total.

Answer 1

An abstract class is not considered as a parent? As far as I understand, a lot of code will be common, the interface is perfectly replaced by an abstract class + how many heirs are needed.

Answer 2

Could it be something like this? the interface is common, it's just that one printer will have to override methods to call a new one with the password passed. I ideally it will be able to use the methods of the base abstract class.
Code on pastebin

Answer 3

The question is, where will this password come from? It can be passed by the same “top level” that will send commands to the printer or some other object that will configure the printer object; as an option - a factory object. This object can be hardcoded for configuration for different implementations of the interface; an alternative is to take as a generalization that there may or may not be a password, in which case we pass an empty string, e.g. A particular implementation may or may not use this password. Total we have:

• configuration file with at least two fields - printer class and password (optional);
• a factory object that reads a file and instantiates an object of the specified class and sets its password and other parameters;
• the caller creates an object and uses it through the interface.

Answer 4

A factory for receiving settings should be injected into a specific printer, or the settings should be directly injected right away. It is not advisable to allocate any passwords to the interface of the printer itself. To use a password or not to use it is a matter of connection with the entity "printer settings" or something like that, but not the "printer" itself. The printer itself should only be able to print directly, and even then, probably, delegate to the "printing part of the printer" or the like.
The basis for identifying a common ancestor is a common responsibility, a common behavior. In this case, "password present/password not present" is neither a shared responsibility nor a shared behavior, but just one of the dependencies needed by only one of the printer types.

Answer 5

Since one of the printers does not need a password, there is no need to introduce it into the methods of the interface (abstract class). It is easier to pass in the constructor of a specific successor.
You can make it optional if you want.