Комментарии 19
|А какие из перечисленных принципов SOLID уменьшают запутанность системы и увеличивают изолированность её модулей?
|А вот и нет. Принцип открытости/закрытости говорит скорее о правильности использования сокрытия, а не о том, насколько модульной получится конечная система.
После первого же вопроса решил дальше не продолжать. Если Open/Closed не способствует изолированности модуля, то пожалуй у нас разное понимание этого термина.
Open/Closed он же про наследование. А в модульных структурах composition over inheritance. Можно сделать жёстко сцепленный монолит, почти не нарушающий open/closed.
Полиморфный вариант не единственный. Для меня приоритетным прочтением будет принцип открытости/закрытости Мейера: A module will be said to be closed if [it] is available for use by other modules.
Собственно, при закрытости модуля, его изменения и расширения не влияют на другие модули. Если пойти от обратного, то отсутствие изолированности - это когда при изменениях модуля А необходимо изменить модуль Б.
Достигается это обычно через полиморфный принцип, введением абстракции (интерфейс - реализация).
OCP можно и в функциональном стиле сделать, и в процедурном, и в каком угодно.
Он не про наследование, а про расширение без модификации, то есть о наличии (закладывании) большого количества степеней свободы для кастомизации при расширении без модификации исходного модуля.
На плюсах это может быть достаточное количество шаблонных параметров или трейтов. В функциональных языках на каждый чих принимать внешние функции (желательно с поведением по умолчанию). Аспектно-ориентированное программирование - это тоже возможная реализация OCP. Ну и так далее.
абсолютно согласен.
Даже если внутри сложный адский класс , то использовать легко как , т.к. "вовне" всего 1 метод.
mySuberBilling.SPISAT_DENEG(userid, 55);
Больше тебе ничего не нужно знать. Если это не "уменьшают запутанность системы и увеличивают изолированность ", то ...
После первого же вопроса решил дальше не продолжать.
Если один принцип каждый понимает по-своему, это не вина его использующих, это проблема принципа. У нас тут программирование, а не религия же.
Вот на том же вопросе офигел) А дальше вопрос про коммуникацию между сервисами, в котором шина данных - единственный правильный вариант
In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
Дядя Фаулер, не знаешь ты о чём пишешь, не добудешь золота.
Итак, теперь монолит может быть расколот, а золотые самородки почти у вас в руках! Но подобно тому, как золото нужно потом собрать вместе, чтобы победно в нём искупаться, так и микросервисы всё ещё остаются частью единого целого.
Как будем обеспечивать взаимодействие между ними? Выберите самый распространённый в микросервисной архитектуре способ.
Взаимодействие зависит от бизнес-процессов. Что-то можно асинхронно (очереди, брокеры), а что-то нужно синхронно (api, rpc). События лучше через шину передавать, а что-то получить проще через http. Мне кажется, что синхронный самый распространённый, так как это проще и быстрее сделать. Довольно холиварный вопрос
Это был тест на время.
Спасибо, что предупредили.
класс может принимать к себе в конструктор объект другого класса и вызывать в нём нужные методы
И почему это не агрегация?
Прикольно. На 2 не ответил верно, потому что .WhenAll это инструмент ожидания всех а не запуска параллельных. Не верно здесь.
Ну и не знал про потокобезопасные массивы. Полезно)
Какой-то легкий тест, хотя и некоторые формулировки смущают.
Соревнование между спецами по .NET и Java: ищем золотые фрагменты кода