pi314

Ок с этим все понятно.

Если с этим все понятно, то не совсем понятно, что же тогда непонятно... В зависимости от того, зачем его, этот анализ, проводят, на выходе может быть все, что угодно - от приказа об увольнении архитектора и вплоть до проработанной модели структурных и поведенческих аспектов разрабатываемой системы, например, в SysML/UML и/или текстовом описании... а может быть и просто идея, как можно взломать эту систему. Короче, как любой прочий анализ, он выделяет элементы для последующего синтеза того, чего нужно ))

Примерно так:

interface IBankAccount
{
 public void AddFunds(double value);
 public void RemoveFunds(double value);
}
...
class BankAccount implements IBankAccount
...
class TransferManager
{
 public TransferManager(IBankAccount Source, IBankAccount Destination, double Value) {
...

...и т.д. Везде заменить прямую зависимость от класса на зависимость от интерфейса, ибо:

- Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
- Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

(Класс - это модуль, а интерфейс - это абстракция.)

Эти принципы просто относятся к разным вещам. IoC предлагает некий способ организации управления потоком выполнения в системе (кто кого почему и когда вызывает), в то время как DIP предлагает соблюдать определенное направление при организации зависимостей (между модулями), основываясь на уровне абстрактности оных.
В общем оба они направлены на повышение качественных характеристик системы (и это в них, как и во всех прочих принципах ООД, действительно общее), только один "подходит к проблеме" со стороны поведенческих аспектов системы, а второй - со стороны структурных.

Полиморфизм - один из трех фундаментальных принципов ООП-парадигмы.

Замещение (также "перекрытие" или "переопределение" методов) - общее название механизма, предоставляемого ЯП для поддержки применения этого принципа при проектировании иерархий классов.

Конкретные детали реализации механизма могут отличаться, (как, например в Java и JS), но суть с т.з. ООП остается той же. А вот в С, например, такого механизма вообще нет, однако это не препятствует (просто не помогает!) писать объектно ориентированный код на этом языке.

Так что, если под "замещением" понимается именно overriding, я бы не стал так широко отождествлять цель и средство ее достижения :)

Объяснить суть полиморфизма "на пальцах" довольно просто. Представьте себе класс Телефон. Его спроектировал некто в далеких 80-х, и определил в нем метод набратьНомер(). А потом другой программист в 90-х отнаследовал от него класс МобильныйТелефон и перекрыл метод набратьНомер(), т.к. грубо говоря, в новом устройстве набор производится уже не импульсно, а тонально. А потом третий программист отнаследовал от него класс Смартфон. При этом он не стал трогать метод набратьНомер(), а просто добавил методы для нового функционала, типа определитьПоложениеПоGPS() и т.д.

Теперь представьте себе пользователя. Он родом из 80-х и понятия не имеет о тональном наборе и GPS... но если ему в руки дать любое из этих устройств, он сможет набрать номер и сделать звонок. Почему? Потому, что он умеет использовать метод набратьНомер(), и большего ему знать не нужно.

А теперь представьте другого пользователя, нашего современника. Он вырос в эпоху смартфонов... но если ему в руки дать старый телефонный аппарат, он тоже сможет сделать звонок, т.к., опять же, знает метод набратьНомер().

Применительно к ООП, пользователь - это переменная, содержащая ссылку на экземпляр класса. Ее тип (как она была объявлена) - это "набор знаний" о возможностях этого экземпляра. И т.к. Смартфон в своей основе является Телефон-ом, мы вполне можем дать его в руки гипотетическому пользователю из 80-х:
Телефон устройство = new Смартфон();
в результате чего он сможет сделать звонок:
устройство.набратьНомер("03");
А вот определить свое местоположение он не сможет, пока не узнает о существовании соотв. метода:

Смартфон усовершенствованноеУстройство = (Смартфон)устройство;

Это называется приведением типа. В данном примере у экземпляра класса уже был соотв. метод, но чтоб им воспользоваться, нужно сначала явно указать, что мы хотим рассматривать имеющееся у нас в руках устройство не как "простой" Телефон, а как Смартфон.

P.S. Кстати, в этом примере мы затронули не только полиморфизм, но и наследование, и инкапсуляцию (пользователя "снаружи" совершенно не интересует, как именно производится набор номера - тонально, импульсно или еще как-то иначе)... так сказать, все три кита ООП в одном флаконе. И только так вообще имеет смысл рассматривать эти принципы, т.к. они по сути неотделимы друг от друга, как Отец, Сын и Святой Дух в Христианстве или же длина, ширина и высота в трехмерном пространстве :) Если это понять, ООП становится совершенно простой и естественной парадигмой программирования.