frontjss, нет, инкапсуляция есть, интерфейс есть, всё есть, но они все равно текут, потому что инкапсуляция не работает для бесконечного круга задач, контекстов использования конкретного кода.
Рано или поздно, на каком языке не пишете, окажется, что производительность программы никуда не годится, и придется отправится в отладочную экспедицию, вооружившись детальными знаниями устройства уровня ниже, часто это касается работы сборщика мусора и модели памяти, предлагаемой языком. Если повезёт, то после смены алгоритма всё будет работать приемлимо, но придется в документации указать, почему вместо простого и понятного алгоритма пришлось применять сложный.
А вот если не повезёт, то вы уткнетесь в специфический баг какой-нибудь dll из корневых библиотек ВМ java, который никто особо торопиться править не будет, потому что с такой проблемой никто ещё не сталкивался. Т.е. по отдельности все работает, код чистый, читаемый, понятный, а вместе всё это не работает. И тут уже просто единственный выход, искать специалиста C++ со стороны, который сделает патч, потому что спасение утопающих дело рук утопающих.
Инкапсуляция скрывает реализацию, поэтому невозможно судить о возможных сайд эффектах. А вот когда эти эффекты проявляются, тогда и говорят, что "абстракция протекла".
frontjss, реализовали вы абстракцию координатной точки. Тесты пройдены, всё хорошо. Но потом оказалось, нужны расчеты в сферичекой системе координат. Или вообще в проективной. И тут оказывается, проблема есть. В том, что весь текущий код зависит от того, что точка характеризуется двумя значениями типа float. По факту , нужно было эту деталь реализации скрыть, и характеризовать точку коллекцией элементов типа класс Координата, которая бы в зависимости от системы координат, релизовывала работу с абстракциям более низкого уровня. Вот это называется, абстракция протекла. Но если бы задача по поддержке других систем координат не возникала, все было бы норм, т.к. код имеет минимально возможную сложность и проходит тесты.
В оригинальной статье был пример с TCP протоколом. Когда для гарантии доставки одного пакета по факту может произойти серия отправок. Там критика шла о том, что композитные решения, которые прикидываются сущностями более низкого уровня за простоту абстрагирования просят плату в виде задержек и медленной работы. В более сложных случаях - возможно с сайд-эффектами, неожиданными исключениями, например, если вместо явного вызова удаленных процедур используется паттерн Репозиторий. И что для обработки исключений , например, бд недоступна, а кэш устарел, и теперь нельзя что-то сделать с помощью абстракции, которая умышленно прикидывается локальным кодом, мол, приходится в кол, который предполагает работу с локальным кодом вставлять обработку исключений доступности БД, и типо, абстракция протекла. Как по мне, тут ничего не течет, потому что это не черный ящик, это паттерн, который либо ты знаешь, и используешь, либо не знаешь и не используешь.
Просто у людей бомбит, что пользоваться черным ящиком - это легко, в эксплуатации инкапсуляция работает на пользователя. А в конструировании она не помогает, потому что к модулям кода нельзя относится как к черным ящикам. Как бы, теория автоматизации систем и теория системного анализа говорят об этом прямо.
frontjss, если речь только про свой код, это может произойти, когда у заказчика поменялись потребности. Поменяется ТЗ, появятся новые фич реквесты, и если потребности поменялись кардинально, то может статься, что придется вносить изменения в модель предметной области. Не прокатило "один раз сделал и забыл". Другой случай, когда не сразу разработчик въехал в предметную область. Пришло понимание, а с ним и изменённая модель.
Ещё другой случай, когда окажется, что часть изменений потребуется внести в модуль, который под авторством коллег. И вот тут придется вникать в их код, для того, чтобы вместе прийти к пониманию нового интерфейса модуля, или нового промежуточного слоя между предметными моделями двух модулей.
SOLID, KISS, DI и все это вот, что помогает писать модульный код, упрощают рефакторинг, но то, что абстракции текут - это неизбежно. Как и неизбежно то, что чем дольше разработка, тем большим экспертом вы становитесь по всей кодовой базе проекта.
Swagger, draw.io, c4model.com, Entity Framework, Datagrid. Но у всех подход свой, технологии разные, процесс разный. Проектируют люди, как хотят, стандарты всегда локальные, уровня предприятия.
В целом проектирование делается один раз, когда ещё нет кода, потом это просто непрерывное документирование изменений, добавление описаний и генерация документации.
UML полезно понимать, но руками по нему рисовать практически никогда не надо. Вот если софтина прочитает код и нарисует - это ещё может быть полезно, в некоторых случаях. Когда нельзя сходу понять, как нужно изменить интерфейс взаимодействия молулей. Но для понимания обычно всем хватает тестов и абстрактных диаграмм связей.
Вообще, прототипирование намного лучше и полезнее проектирования на бумажке. Во первых, есть код, который говорит сам за себя, намерения выражены однозначно, а во-вторых, все что рисуется до кода, а не генерируется из кода, это просто предположения, ложь и провокация, потому что знаний о разрабатываемой системе пока что 0. Все, что рисуется до кода всегда выбрасывается.
Иные варианты ещё костыльнее. Либо when: manual, либо create merge request от issue с изменениями в неком дополнительном текстовом файле в репозитории (пустой мердж реквест не триггерит пайплайн).
Такая функциональной ещё не реализована. Но в принципе, проблема в том, что архитектурно подразумевается, что gitlab-runner живёт в отдельном окружении на билд-сервере, а не на сервере приложений, где крутится gitlab, о котором раннер ничего и не должен знать.
Что там учить, ~30 ключевых слов и структурная парадигма.
Волновать должны доки по компиляторам и железкам. Даже по библиотекам - конекстно зависимая разработка, как она есть, потому что, то, что в коде обычный int, а в контексте - идентификатор какой-нибудь базовой для предметной модели библиотеки сущности. Колбеки и автоматы состояний, эмуляция наследования через расположение одинаковое расположение полей. Это вообще другой уровень мышления в решении задач.
Из радости только скорость работы кода.
Рано или поздно, на каком языке не пишете, окажется, что производительность программы никуда не годится, и придется отправится в отладочную экспедицию, вооружившись детальными знаниями устройства уровня ниже, часто это касается работы сборщика мусора и модели памяти, предлагаемой языком. Если повезёт, то после смены алгоритма всё будет работать приемлимо, но придется в документации указать, почему вместо простого и понятного алгоритма пришлось применять сложный.
А вот если не повезёт, то вы уткнетесь в специфический баг какой-нибудь dll из корневых библиотек ВМ java, который никто особо торопиться править не будет, потому что с такой проблемой никто ещё не сталкивался. Т.е. по отдельности все работает, код чистый, читаемый, понятный, а вместе всё это не работает. И тут уже просто единственный выход, искать специалиста C++ со стороны, который сделает патч, потому что спасение утопающих дело рук утопающих.
Инкапсуляция скрывает реализацию, поэтому невозможно судить о возможных сайд эффектах. А вот когда эти эффекты проявляются, тогда и говорят, что "абстракция протекла".