Включение Cofoja в проект может быть по-разному. Но лучше придерживаться того, что предлагают авторы, используя аргумент jvm -javaagent при запуске приложения.
На проект пока не повлиял сильно, т.к. не все разработчики придерживаются Design by Contracts. Грамотность разработчиков надо повышать, т.е. разобрать примеры использования и найти соглашение применения Cofoja, т.к. кто-то хочет использовать Cofoja как assert’ы c отключениями на prod, а кто-то считает, что Design by Contracts должен делать проверки в любом случае.
Всему нужен баланс. Один из примеров подхода данных принципов является покрывать код тестами, тогда он станет ближе к вновь использованному классу. Созданный таким образом класс будет иметь больше вероятности для нового использования класса, а не переписывания его заново.
Данный подход не панацея, а добавляет удобство в использовании. На практике бы предложил разделить ответственность на поведение наследуемого класса таким образом:
— у public методов и классов отвественность лежит на разрабочике класса родителя
— у protected методов и классов отвественность лежит на разрабочике потомка
При такой ответственности становится проще создавать такие классы.
На проект пока не повлиял сильно, т.к. не все разработчики придерживаются Design by Contracts. Грамотность разработчиков надо повышать, т.е. разобрать примеры использования и найти соглашение применения Cofoja, т.к. кто-то хочет использовать Cofoja как assert’ы c отключениями на prod, а кто-то считает, что Design by Contracts должен делать проверки в любом случае.
При такой ответственности становится проще создавать такие классы.