AD
1) проблема надуманна
Х.х. и в продакшн?
Size: a a a
2020 September 27
ПК
Х.х. и в продакшн?
Тем более
AD
Тем более
Что тем более, вы просто пишете "как нибудь" без задней мысли и думания о последствиях?
ПК
Что тем более, вы просто пишете "как нибудь" без задней мысли и думания о последствиях?
Надо просто публичный контракт грамотно дизайнить. И потом чтоб публичный интерфейс ему соответствовал и не ломал
ЕП
Думал что кому-нибудь интересно будет
ЕП
Всем привет
ЕП
Плюсы превращаются в кашу
ПК
ЕП
Вы меня на мемы тащите?
ЕП
Читал что в Go что-то подобное есть
ЕП
В новых языках проще с новыми фичами так как чистый лист не имеет сформировавшего скелета
ЕП
Нет риска нарушить согласованную картину
m
yield_value разве можно без аргументов? (ну и соответственно co_yield без expression?)Действительно нельзя. Да и возвращать
yield_value() должен awaitable. Сейчас добавлю апдейт, что этот код - бред.m
Господа, меня вот какой "архитектурный" вопрос волнует..
Предположим есть несколько объектов (не имеющие наследственной связи), которые должны как-то общаться между собой (например иметь ссылки друг на друга, или просто доступ к чужим данным, не суть важно).
Очевидно что в этом случае мы можем пойти как минимум 2мя путями:
1) Объявить некий публичный интерфейс к нужным данным.
2) Объявить некий приватный интерфейс и тупо начать френдить.
Оба варианта как по мне тухлые:
1 - создаёт опасность того, что этим интерфейсом воспользуется тот, кто им воспользоваться не должен.
2 - создаёт прям-таки железобетонные связи между классами, которые потом проблематично отслеживать и модерировать.
Ну и френды считаются мувитоном и признаком хреновой архитектуры, насколько я понимаю.
Собственно существует ли какая-то хитрость до которой я не догоняю, или проблема на самом деле надуманна?
Предположим есть несколько объектов (не имеющие наследственной связи), которые должны как-то общаться между собой (например иметь ссылки друг на друга, или просто доступ к чужим данным, не суть важно).
Очевидно что в этом случае мы можем пойти как минимум 2мя путями:
1) Объявить некий публичный интерфейс к нужным данным.
2) Объявить некий приватный интерфейс и тупо начать френдить.
Оба варианта как по мне тухлые:
1 - создаёт опасность того, что этим интерфейсом воспользуется тот, кто им воспользоваться не должен.
2 - создаёт прям-таки железобетонные связи между классами, которые потом проблематично отслеживать и модерировать.
Ну и френды считаются мувитоном и признаком хреновой архитектуры, насколько я понимаю.
Собственно существует ли какая-то хитрость до которой я не догоняю, или проблема на самом деле надуманна?
Я с таким в основном встречался когда два класса жестко связаны. Например контейнер и итератор. В таких случаях я обычно объявляю итератор внутри контейнера, а контейнер использует только публичный интерфейс итератора.
AD
Корутины для невнимательных инженеров
Внимательность антипаттерн
ПК
Внимательность антипаттерн
А без нее никуда в программировании
ЕП
Побитый кирпич, поддерживаю
ЕП
Ники перепутал
AD
А без нее никуда в программировании
Вообще говоря, это есть лимитирующий фактор надёжности, по сему, чем больше исключаешь её влияние, тем надёжнее будет работать.