Да, я постоянно вижу, как в качестве примера приводят либо хранилище файлов либо какое-то key-value. Конечно для них подойдет такая схема с интерфейсом и чтобы заменить можно было потому что там 3 функции всего в интерфейсе: создать, прочитать, удалить.
Случай с базой совершенно другой, там в интерфейсе будет примерно столько же функций, сколько апишек HTTP в этом сервисе. Эта ситуация совершенно другая с точки зрения принципа Low Coupling - High Cohesion. В случае хранилища файлов внешних связей мало, так что можно его отделить, а в случае базы внешних связей будет максимально возможное количество, поэтому и отделять его - плохая идея.
Тестами и HTTP хендлеры прекрасно покрываются + в проекте бывает небольшой набор чисто вычислительных функций с хитрой логикой, для которых чистые юнит тесты отлично подходят.
Вот следующий шаг после "общей структуры" - а я сделал небольшое изменение/фикс в общий код, как теперь на все проекты распространить? И тут появляется необходимость в генераторе кода проекта с возможностью апдейта.
Давно пора уже от этой слоеной архитектуры отказываться, горячо поддерживаю. Надоело уже это писать чтоб json в базу сохранить и обратно строчки из базы в виде json выдать. И так всё прекрасно понятно без этих репозиториев и прочих.
Нормальная игра, я купил и прошел до конца. Про графику многие написали уже, довольно красивая даже по современным меркам. Сюжет да, линейный. Но и в киберпанке, к примеру, особых вариантов нет. Все сводится к одному, просто чуть по разным веткам в самом конце туда приходишь.
Недовольство тем, что игру на месяц задержали очень странное, мало какие проекты в срок выходят. Ну задержали и задержали. Сразу после релиза во всех играх практически много багов. Я поиграл в ноябре, у меня за 40 часов один баг только возник - пройденное задание не засчиталось, просто сохранение открыл и всё.
Ну и надо понимать, что тут всё-таки вольностей можно было гораздо меньше позволить себе, так как было довольно четкое ТЗ и игра хоть немного но претендует на соответствие реальной истории.
А кто код-то писать будет? Условные разработчики из интела на зарплате в режиме фулл-тайм пилят поддержку своего железа имея на руках не только всю необходимую документацию, но и тесные связи с самими разработчиками железа.
И вот сделает кто-то форк а работу по написанию и доработке драйверов кто будет делать?
Подушню немного. Вот у всем известного товарища, который книги пишет и эти принципы продвигает совсем другое написано про принцип единственной ответственности. Класс должен обслуживать только одно заинтересованное лицо. Там был пример про рабочие часы: в компании рабочие часы сотрудника надо знать сотруднику бухгалтерии для расчета ЗП и, к примеру, службе безопасности. И эти функции/классы для расчета рабочих часов не должны быть одним. Нужна отдельная функция для расчета рабочих часов для бухгалтерии и отдельная - для службы безопасности.
Если для бухгалтерии надо 500 функций - их можно в один класс запихнуть и не будет противоречия с этим принципом.
Так а если флеш-память и крипто-модуль будет на одном кристалле? Если на раздельных - то понятно, что как-то к проводкам можно будет подключиться, но вот чтобы к дорожкам на кристалле что-то подсоединяли я не слышал еще
Я думаю там технология, похожая на всяческие рутокены - то есть некоторая микросхема зашифровать сможет, если ей на вход подать исходные данные, но вытащить сертификат из микросхемы нельзя. Ну а далее каждый производитель фотоаппаратов обзаводится своим сертификатом, который подписывает сертификаты, которые уже прошиваются в эту крипто-микросхему в каждой камере.
Вроде нет подвоха, кроме того, что у производителя камер могут украсть сертификат и что тогда делать с проданными камерами - неясно. То есть по-хорошему этот украденный сертификат надо будет добавить в список отозванных, выпустить новый сертификат производителя и потом каждый владелец камеры должен будет бежать в какой-то авторизованный сервисный центр, где ему в камеру новый пропишут? И все снятые видосы, подписанные этим сертификатом окажутся невалидными.
Nevi-rus написал про стекла для фотографов, и эта ветка мне кажется именно про фотообъективы. Я же написал, что для фото объектив без автофокуса не нужен.
Они по-большому счету нужны всяким энтузиастам в коллекцию, не знаю, кто в здравом уме для фото будет покупать мануальный объектив сейчас. Разве что tilt-shiftы для архитектуры еще можно потерпеть без автофокуса.
Ну вот SRP вы совсем не тот написали, про который Роберт Мартин писал. Там идея в том, чтобы код, который нужен разным акторам (у него в примере это администраторы баз данных, отдел бухгалтерии и отдел по работе с персоналом) лежал в разных модулях и не использовал общих функций.
То есть вынести какой-то алгоритм в отдельный класс, как вы написали - это ровно то, чего делать не нужно. Следует копипастить код, который нужен разным акторам согласно этому принципу.
Если что - я не сторонник SOLID, просто постарался максимально понять эти принципы.
Да, я постоянно вижу, как в качестве примера приводят либо хранилище файлов либо какое-то key-value. Конечно для них подойдет такая схема с интерфейсом и чтобы заменить можно было потому что там 3 функции всего в интерфейсе: создать, прочитать, удалить.
Случай с базой совершенно другой, там в интерфейсе будет примерно столько же функций, сколько апишек HTTP в этом сервисе. Эта ситуация совершенно другая с точки зрения принципа Low Coupling - High Cohesion. В случае хранилища файлов внешних связей мало, так что можно его отделить, а в случае базы внешних связей будет максимально возможное количество, поэтому и отделять его - плохая идея.
Тестами и HTTP хендлеры прекрасно покрываются + в проекте бывает небольшой набор чисто вычислительных функций с хитрой логикой, для которых чистые юнит тесты отлично подходят.
Вот следующий шаг после "общей структуры" - а я сделал небольшое изменение/фикс в общий код, как теперь на все проекты распространить? И тут появляется необходимость в генераторе кода проекта с возможностью апдейта.
По всем слоям логику искать тоже не особо приятно, совсем не ускоряет процесс разработки.
Давно пора уже от этой слоеной архитектуры отказываться, горячо поддерживаю. Надоело уже это писать чтоб json в базу сохранить и обратно строчки из базы в виде json выдать. И так всё прекрасно понятно без этих репозиториев и прочих.
Надо попробовать, как раз есть такой )
Нормальная игра, я купил и прошел до конца. Про графику многие написали уже, довольно красивая даже по современным меркам. Сюжет да, линейный. Но и в киберпанке, к примеру, особых вариантов нет. Все сводится к одному, просто чуть по разным веткам в самом конце туда приходишь.
Недовольство тем, что игру на месяц задержали очень странное, мало какие проекты в срок выходят. Ну задержали и задержали. Сразу после релиза во всех играх практически много багов. Я поиграл в ноябре, у меня за 40 часов один баг только возник - пройденное задание не засчиталось, просто сохранение открыл и всё.
Ну и надо понимать, что тут всё-таки вольностей можно было гораздо меньше позволить себе, так как было довольно четкое ТЗ и игра хоть немного но претендует на соответствие реальной истории.
Вроде бы Eagle для того же служит, но я его один раз только запускал - испугался и закрыл.
Это же дистрибутив линукса а не "новая операционная система", зачем вводить слушателей в заблуждение?
У них есть получше объектив, тот что в статье - это дешевый и для камер APS-C
https://www.canon.ru/lenses/rf-5-2mm-f2-8l-dual-fisheye-lens/
А кто код-то писать будет? Условные разработчики из интела на зарплате в режиме фулл-тайм пилят поддержку своего железа имея на руках не только всю необходимую документацию, но и тесные связи с самими разработчиками железа.
И вот сделает кто-то форк а работу по написанию и доработке драйверов кто будет делать?
Подушню немного. Вот у всем известного товарища, который книги пишет и эти принципы продвигает совсем другое написано про принцип единственной ответственности. Класс должен обслуживать только одно заинтересованное лицо. Там был пример про рабочие часы: в компании рабочие часы сотрудника надо знать сотруднику бухгалтерии для расчета ЗП и, к примеру, службе безопасности. И эти функции/классы для расчета рабочих часов не должны быть одним. Нужна отдельная функция для расчета рабочих часов для бухгалтерии и отдельная - для службы безопасности.
Если для бухгалтерии надо 500 функций - их можно в один класс запихнуть и не будет противоречия с этим принципом.
Так а если флеш-память и крипто-модуль будет на одном кристалле? Если на раздельных - то понятно, что как-то к проводкам можно будет подключиться, но вот чтобы к дорожкам на кристалле что-то подсоединяли я не слышал еще
Расскажите тогда, как с рутокена вытащить сертификат?
Я думаю там технология, похожая на всяческие рутокены - то есть некоторая микросхема зашифровать сможет, если ей на вход подать исходные данные, но вытащить сертификат из микросхемы нельзя. Ну а далее каждый производитель фотоаппаратов обзаводится своим сертификатом, который подписывает сертификаты, которые уже прошиваются в эту крипто-микросхему в каждой камере.
Вроде нет подвоха, кроме того, что у производителя камер могут украсть сертификат и что тогда делать с проданными камерами - неясно. То есть по-хорошему этот украденный сертификат надо будет добавить в список отозванных, выпустить новый сертификат производителя и потом каждый владелец камеры должен будет бежать в какой-то авторизованный сервисный центр, где ему в камеру новый пропишут? И все снятые видосы, подписанные этим сертификатом окажутся невалидными.
Кило пластика стоит 1000р. На вид этот кораблик вряд ли больше 100кг весит, а 100 т. р. не так уж много, учитывая сколько времени на это потрачено.
Nevi-rus написал про стекла для фотографов, и эта ветка мне кажется именно про фотообъективы. Я же написал, что для фото объектив без автофокуса не нужен.
Они по-большому счету нужны всяким энтузиастам в коллекцию, не знаю, кто в здравом уме для фото будет покупать мануальный объектив сейчас. Разве что tilt-shiftы для архитектуры еще можно потерпеть без автофокуса.
Это второй такой объектив, первый был вот этот для полнокадровой R5 - https://www.canon.ru/lenses/rf-5-2mm-f2-8l-dual-fisheye-lens/
А новый видимо подешевле и для кропа
Ну вот SRP вы совсем не тот написали, про который Роберт Мартин писал. Там идея в том, чтобы код, который нужен разным акторам (у него в примере это администраторы баз данных, отдел бухгалтерии и отдел по работе с персоналом) лежал в разных модулях и не использовал общих функций.
То есть вынести какой-то алгоритм в отдельный класс, как вы написали - это ровно то, чего делать не нужно. Следует копипастить код, который нужен разным акторам согласно этому принципу.
Если что - я не сторонник SOLID, просто постарался максимально понять эти принципы.