Есть способ проще - берешь набор из 4 слов с неповторяющимися буквами и вуаля - если немного подумать, то можно составить 5 слово исходя из полученных данных
Там не совсем инкапсуляция, и к ООП он не относится, ну да ладно. Я имею в виду пример с самолётами, он слишком натянутый, при нормальной архитектуре в ООП такого не должно случаться, если уж зависимость так необходима. Да, дедлоки случаются, обычно при добавлении функционала, которого изначально не было предусмотрено, но это лишь причина пересмотреть архитектуру приложения. При работе с бд в примере, вам нужно создать объект типа похожего по функционалу на lockguard для блокировки изменения данных строки в БД. Просто ещё один класс. И он уже будет освобождать строку был в деструкторе. Это один из вариантов решения.
Да откуда дедлокам то взяться? Ресурс один - блокировщик один на чтение и запись, пока не завершится работа с данными. Если нужно, можно сделать парадлельное чтение, но на запись нужен второй блокировщик, который и чтение запретит. И это уже реализовано в БД и не связано с ООП вообще ни как
А вариант примера решения без ооп будет? И как объект "диспетчер" оказался в управляемых объектах? И ооп в этом примере за уши притянут. Согласен, проблемы есть, как и есть способы их решений, но пример на псевдокоде - это вообще не ооп ни разу, обычное процедурное программирование.
Мне кажется тут хвалиться нечем. Был ли какой либо особый функционал? Абсолютно ничего нового, по сравнению с другими магазинами. Даже детский режим очень странный. Просто вот так вот повезло, что санкционные компании выкладывают свои приложения только там.
Вообще, конечно, если сервис не позволяет настраивать секюрность, то так себе сервис. Например добавить правила для тонкой настройки пересылок, если их нет. Правила для получателей в зависимости от прав пользователя. Например обычный юзер не может отправлять письма вне компании, только внутренние и плюс белый список. Менеджер по продажам может всем слать, но автоматическая пересылка наружу запрещена.. ну и т.п. нормально делайте - нормально будет
Да, проблема есть, высшие органы решили, что нефиг поддерживать ИТ в Москве и Питере. Но т.к. компаний зарегистрированных в Подмосковье тоже не очень много, наверное только те, кто в Сколково, то и в условном Одинцово квартиру тоже не купить. По семейной ипотеке лимиты на столько низкие при высоком первоначальном взносе, что не понятно, какой семье нужна эта однушка за мкадом через три года.
Как связан API с UX? UX вообще связан с технической частью очень символически. UX - это скорее про логику взаимодействия с пользователем, тестирование, ближе к психологии, чем к разработке или дизайну. UI ещё понятно, но это просто интерфейс, который лежит сверху на фронтенде.
Функциональное программирование - это не про создание функций. В ядре линукса не функциональный подход, а процедурный, с частичками ооп. Если брать чисто функциональные языки, наверное это лисп.. больше вспомнить не могу
Ну и что же мешает их использовать для вывода графики на с++? Я с разбегу даже не вспомню, какой вообще язык поддерживает графику из коробки, в основном это сторонние библиотеки или модули
Так там ещё и думать надо, скрипт то не думает
Есть способ проще - берешь набор из 4 слов с неповторяющимися буквами и вуаля - если немного подумать, то можно составить 5 слово исходя из полученных данных
А оператор не настраивает переадресацию вызовов, чтобы это все работало?
Там не совсем инкапсуляция, и к ООП он не относится, ну да ладно. Я имею в виду пример с самолётами, он слишком натянутый, при нормальной архитектуре в ООП такого не должно случаться, если уж зависимость так необходима. Да, дедлоки случаются, обычно при добавлении функционала, которого изначально не было предусмотрено, но это лишь причина пересмотреть архитектуру приложения. При работе с бд в примере, вам нужно создать объект типа похожего по функционалу на lockguard для блокировки изменения данных строки в БД. Просто ещё один класс. И он уже будет освобождать строку был в деструкторе. Это один из вариантов решения.
Да откуда дедлокам то взяться? Ресурс один - блокировщик один на чтение и запись, пока не завершится работа с данными. Если нужно, можно сделать парадлельное чтение, но на запись нужен второй блокировщик, который и чтение запретит. И это уже реализовано в БД и не связано с ООП вообще ни как
А вариант примера решения без ооп будет? И как объект "диспетчер" оказался в управляемых объектах? И ооп в этом примере за уши притянут. Согласен, проблемы есть, как и есть способы их решений, но пример на псевдокоде - это вообще не ооп ни разу, обычное процедурное программирование.
Мне кажется тут хвалиться нечем. Был ли какой либо особый функционал? Абсолютно ничего нового, по сравнению с другими магазинами. Даже детский режим очень странный. Просто вот так вот повезло, что санкционные компании выкладывают свои приложения только там.
Вообще, конечно, если сервис не позволяет настраивать секюрность, то так себе сервис. Например добавить правила для тонкой настройки пересылок, если их нет. Правила для получателей в зависимости от прав пользователя. Например обычный юзер не может отправлять письма вне компании, только внутренние и плюс белый список. Менеджер по продажам может всем слать, но автоматическая пересылка наружу запрещена.. ну и т.п. нормально делайте - нормально будет
Да, проблема есть, высшие органы решили, что нефиг поддерживать ИТ в Москве и Питере. Но т.к. компаний зарегистрированных в Подмосковье тоже не очень много, наверное только те, кто в Сколково, то и в условном Одинцово квартиру тоже не купить. По семейной ипотеке лимиты на столько низкие при высоком первоначальном взносе, что не понятно, какой семье нужна эта однушка за мкадом через три года.
Как связан API с UX? UX вообще связан с технической частью очень символически. UX - это скорее про логику взаимодействия с пользователем, тестирование, ближе к психологии, чем к разработке или дизайну. UI ещё понятно, но это просто интерфейс, который лежит сверху на фронтенде.
Если менеджер напрямую взаимодействует с членами команды разработки минуя тимлида - это очень плохой подход.
Зато будете алгоритмы знать 😁
Если корабль будет штормит, пусть попробуют потыкать в экран
Ожидал увидеть статью про ФП, но увидел в основном процедурное. разочаровался :(
Функциональное программирование - это не про создание функций. В ядре линукса не функциональный подход, а процедурный, с частичками ооп. Если брать чисто функциональные языки, наверное это лисп.. больше вспомнить не могу
После первого или второго?
Ну и что же мешает их использовать для вывода графики на с++? Я с разбегу даже не вспомню, какой вообще язык поддерживает графику из коробки, в основном это сторонние библиотеки или модули
Польша - это ворота в восточную Европу, видимо так считалось. Некоторые виды поддержки Гугла для России были в Польше, помню мне оттуда звонили
Лучше бы сначала научились анализировать стили, а не вот это всё
А как же ровербук?