А не удобнее ли будет реализовывать всё это не через поля и методы, а через свойства? Результат выйдет тот же, но код будет лаконичнее в обращении.

проанализировав можно понять как работает... Дак что именно "мост" - не сказано, пальцем не показано. 2 иерархии классов связанные друг с другом, а где мост то?

Очень доступно и понятно, спасибо )

Блокировка нужна, иначе при создании может быть несколько экземпляров класса

#include <iostream> #include <string> #include <memory> class DataBaseHelper final { private: static std::unique_ptr<DataBaseHelper> data_base_connection; std::string data; private: DataBaseHelper() { std::cout << "Подключение к БД" << std::endl; } public: DataBaseHelper(const DataBaseHelper&) = delete; DataBaseHelper& operator=(const DataBaseHelper&) = delete; static DataBaseHelper* get_connection() { if(!data_base_connection) { data_base_connection = std::unique_ptr<DataBaseHelper>(new DataBaseHelper()); } return data_base_connection.get(); } std::string select_data() { return data; } void insert_data(const std::string& d) { data = d; std::cout << "Новые данные: " << data << " внесены в БД" << std::endl; } }; std::unique_ptr<DataBaseHelper> DataBaseHelper::data_base_connection = nullptr; int main() { const auto connection = DataBaseHelper::get_connection(); connection->insert_data("123"); std::cout << connection->select_data() << std::endl; return 0; }

кратко сухо и с примером - спасибо! Идеально было бы выложить исходник

К сожалению вообще ни о чем объяснение. Почти 10 минут что-то кодишь а толку?

вроде как этот паттерн еще называют "приспособленец"

А в чём проблема через темплейты такой функционал реализовать? Решение через темплейты выглядит как-то более лаконично

Спасибо Вам большое.

Наверное дискретизация будет Sampling(), а не Simpling(). За материал спасибо!

И в этом весь смысл фасада?.. внедрение а ля композиция в качестве реализации клиентского класса… не зря говорил кто-то, что фасад - это если у вас с архитектурой совсем беда, х.рачь все в годобжект, пусть клиент управляет через одну точку входа… не представляю, где в здравом уме можно это все винтить…

Красава, очень круто

Спасибо, ты крут) Могу лишь добавить, что с рефлексией можно легко обойти ограничения данного паттерна =) Но зачем?)

Отличное видео, только звук фонит.

Самый понятный паттерн, как по мне. При чём он как сам по себе понятный, так и понятно где и как его стоио применять.

Можно еще unique_ptr использовать вместо *.

Что вы как роботы говорите-то без понятных объяснений. Нафиг такие ролики то нужны

шапка канала так и говорит: "You shall die"

Минус за гнусавый голос бота

И нахуй оно нужно?

Подскажите, а зачем в IVisitor указывать метакласс ABCMeta, а не просто указать ABC?

спасибо за видео, помогло и на удивление очень мало видео с прикладными примерами на С++

Полное дерьмо!! из примеров вообще не понятно нахрена так заморачиваться? А что будет, если если передать японский двигатель в российский авто.

Тут не будет утечки памяти из-за того, что в IDeveloper необъявлен деструктор виртуальный?

Спасибо большое! :)

Хотелось бы добавить специальный метод __del__(self), который будет возвращать свойство __db_connection к None при удалении экземпляра

Зачем функции засовывать в классы? Почему бы в ResourceReader не передавать сами функции?

Хорошие видео. еще бы с утечками что-то делал и вообще супер было бы.

В «интерфейсах» лучше реализовывать выброс not implemented error… имхо… тогда разрабы, забывшие реализовать поведение этого интерфейса, будут сразу получать exception

в чем отличие от паттерна фабричный метод?

пушка ничего лишнего на пальцах

Проблема 99% подобных обучающих материалов в том, что демонстрация применения паттерна осуществляется в искусственном окружении, на искусственном примере. Суть паттерна поймет любая обезьяна, а написать примитивный код сможет даже шимпанзе. Где наглядно можно продемонстрировать неправильную работу функционала и правильную (паттерн) это в геймдеве. А если не в геймдеве, то среднестатистический интерн (джун?) не сможет понять куда как и когда это паттерн засовывать, так как у него нет опыта в проектировании сложных систем где такие паттерны могут применяться.

А если потребуется удалить условный hamming, а всё остальное оставить, то как это сделать?

+++

Переменные kg и lb создаются на стеке, а не выделяются динамически с помощью new, поэтому вызывать на них delete - ошибка.

спасибо, разобрался после вашего ролика

невыносимый голос

Благодарю интересно

Все кратко и по делу. Просто Отлично

тут вроде как ТРИ РАЗНЫХ ПОСЕТИТЕЛЯ . .. и каждый посещает по одному месту . . . я ожидал что ОДИН посетитель посетит три разных места

спасибо

если 3 раза запустить конвеер, то получим состояния : off >>> on > on > on; а потом 3 раза нажать cancel, получим: on < off < off <<< off, т.е. промежуточные состояния не соотвествуют друг-другу. Поэтому вместо того что бы просто пушить все нажатия в стак, нужно сначала проверить, адекватна ли команда (меняется ли состояние или нет), в противном случае игнорировать нажатие.

Спасибо!!!!

Материал хороший, но было бы круто пример схож с фабрикой или телефоном, слишком абстрактно

а деструктор прописывать не надо, потому что статичный обьект существует до конца работы программы?

И всё же спасибо за видео! //Интерфейс - абстрактное представление выпуска нового автомобиля class IProduction { public: virtual void Release() = 0; virtual ~ IProduction() {} }; // Интерфейс абстрактного цеха по производству автомобилей class IWorkShop { public: // метод, возвратит абстрактный автомобиль virtual IProduction* Create() = 0; virtual ~ IWorkShop(){} }; да, добавить деструкторы и динамическое освобождение памяти int main() { // code // delete creator; delete car; delete truck; }

Зачем говорить как искусственный интеллект, мерзкий голос

Надо было сначала подкинуть андроид девелопера и сделать полную версию телефона, а потом яблочнх разрабов и сделать урезанную версию, тогда бы получился айфон на андроиде

Очередное тупое видео, где не указаны ни ссылки на исходники ни на само apk работающего приложения, бесполезный шлак текста