Hi!

Suppose you have a Bridge hierarchy like this:

Abstraction: BasicFileSystem → VersionControlFileSystem

Implementations: Fat, NTFS, APFS

One of the abstractions (VersionControlFileSystem) can only work with a specific implementation (NTFS, APFS).

Instead of requiring client to know about this implication when instantiating Abstractions & Implementations, you could provide abstract factory to create necessary classes (and maybe even handle errors when non-existent pairs are requested). Below is a pseudocode:

interface FileSystemFactory {
    createBasicFileSystem() → BasicFileSystem
    createVersionControlFileSystem() → VersionControlFileSystem
}

class WindowsFileSystemFactory {
    createBasicFileSystem() → BasicFileSystem + Fat
    createVersionControlFileSystem() → VersionControlFileSystem + NTFS
}

class macOsFileSystemFactory {
    createBasicFileSystem() → BasicFileSystem + Fat
    createVersionControlFileSystem() → VersionControlFileSystem + APFS
}

Hi!

Thanks for pointing it out. I think I needed to reword that item.

What I meant is that you don't need a class hierarchy to implement a prototype. You can have a working prototype right in the base class, so no inheritance is really necessary (if you don't have subclasses).

On the other hand, the factory method doesn't really make sense without a class hierarchy.

Здраствуйте!

Спасибо за вопрос! Хочу подчеркнуть, что именно следование этому принципу обеспечивает расширяемость и гибкость программного обеспечения, позволяет избежать дублирования кода и улучшает повторное использование кода. Такое следование не получается само-собой автоматически при наследовании.

Например, один из шагов алгоритма подразумевает, скажем, что вы сохраняете файл (этим вы задаёте неявный инвариант метода - наличие нового файла - это один из пунктов в определении принципа Лисков), а следующий шаг с этим файлом что-то делает. Затем вы отнаследовали первый метод и убрали сохранение файла, а значит нарушили инвариант метода, а значит и LSP (ну и, вероятно, сломали работу класса).

They only focus on patterns for now.

Hi!

Sorry for the confusion. I mean that all the subclasses already implement it implicitly if the superclass implements it explicitly. In other words, you can't refuse to have some parts of the original interface in a subclass, it already implements it and you can't change that.

Hi!

Thanks for asking! I appreciate your interest in my work. As you probably know, the course is only available in English right now. I plan to translate it after I finish the second edition of the course. I don't want to waste translation effort on things that might change. I don't have any solid release dates yet. Still, note that if you order the course now, you will access the translated version once it's released.

I'm glad that my work was helpful to you!

Thank you for the kind words!