（Unity 上での C# で考えているので、ほかの言語・環境だと違うかも？）
電源プラグやUSBケーブルを見せるのが手っ取り早いかもしれません。
色々な形の端子があるとややこしいから、これに揃えるんだぞとか。
@radian-jp 2020-09-10 11:43（抜粋）
https://qiita.com/yutorisan/items/d28386f168f2f3ab166d#comment-d2d4657a033d99b6e65d
一般的に、インターフェースなどのオブジェクト指向をわかりにくくしている原因は包丁でくぎを打っているような内容が部分的に含まれているためではないかということに気づきました。
@J_Cotan(J COTAN) 2020-09-24 09:12（抜粋）
https://qiita.com/yutorisan/items/d28386f168f2f3ab166d#comment-233a43235d55ea91823b
なにができるかで議論すると、間違った使い方をしてしまう危険があります。
@J_Cotan(J COTAN) 2020-09-26 07:58（抜粋）
https://qiita.com/yutorisan/items/d28386f168f2f3ab166d#comment-cd299d16e1d37bfd5a9a
抽象クラスという名前は極めて悪質であるように思う。ここまで読んでくれたなら、そして、継承に苦しめられた人ならわかってくれると思うのだが、抽象クラスは往々にして具象を含むのだ。
id:u_osusi 2022-06-29（抜粋）
https://nigiri.hatenablog.com/entry/2022/06/29/233247
以上を踏まえ、以下の理解をしている。
abstract class：全国向けの自販機（の中身）
たぶん、日本語で「抽象」と捉えると実態とずれる。実際には、具体クラスとの対比的な概念として「ざっくりした」クラスというのが英語圏での認識だったりしないだろうか？それなら具体的な要素が入り込む理由も分かる。ほとんどの国・地域で使う機能・機構は、（法的な理由による「おま国」やインフラの問題で、たとえ余分なものがあったとしても）製造コストの観点から共通化したいところが出てくる。
concrete class：ローカル仕様の自販機（の中身）
全国向けの自販機を改造したもの。元々付いている機構を取っ払って、内部を完全に別物にすることもあるし（override した関数内で、base.Something() を書かず別の処理だけを書く）、動作を追加することもある（base.Something() を書いて、その前後に追加の処理を書く）。投入されたコインを分類する機構をヨーロッパ仕様のものと入れ替えたり、新紙幣に対応させるなど。
interface：自販機のボタン、硬貨・紙幣の投入口、取り出し口、硬貨返却口、等
自販機の利用者は国・地域が違っても同じように使いたいし、製造者はそのニーズに合わせるよう要求される。もちろん、勝手に商品や代金などを盗まれないようにもしたい。
まとめ
- 信頼すると決めた相手（大元の製造者や委託先など）に、内部処理をいじってもらう前提なら、抽象クラスを継承して具体クラスを書いてもらう実装にする。
- 信頼すると決められない相手（自販機の利用者・補充アルバイトなど）に、ひたすら使うことに専念してもらうなら、インターフェースを実装して、それに合わせてもらう。
インジェクションができるとか、テスタブルだとか機能的なことは、構造次第で、たぶんどっちでもできる。コードの変更容易性も、IDE の静的解析とか一括リネームとかでどうにかなったりする。
それよりも、どの立場の人間がコードを書くのか、という人間側の事情に合わせることが大事。関係者の規模や分担の仕方、流儀・スキルによって、快適な 構造は異なる。
取り扱うデータの入出力は、基本的にはインターフェースからの経路を考える。インターフェースがない or 機能不足なら（必要性・妥当性のある範囲で）、クラスのプロパティやメソッドなどを触る。
追記
この記事を書いたきっかけ：
シングルトンへの直接のアクセスは、あらかじめ定めておいたごく少数の箇所からのみ行うようにします。そして他のコードからは、インタフェースを通じてアクセスするのです。
https://プログラマが知るべき97のこと.com/エッセイ/シングルトンパターンの誘惑に負けない/
これがどういうことか理解したかった。