RM
А с хера ли одно другому мешает?
Size: a a a
2021 June 24
RM
Не мешает
RM
Легко читать и понимать - это понятие растяжимое
RM
Я вот к примеру не могу врубиться в тригонометрую, только на примерах и когда на пальцах объясняют
RM
Сложность - понятие растяжимое
O
Легкочитаемый код – это когда тебе не надо по новой изучать каждую абстракцию внутри = кишки наружу. Такой код действительно читать легко, но в целостную картину он не сложится
А у понятного кода внутри очень много сложных штук и абстракций, обеспечивающих эту простоту
Темы сопровождения я даже не касаюсь
А у понятного кода внутри очень много сложных штук и абстракций, обеспечивающих эту простоту
Темы сопровождения я даже не касаюсь
RM
Верно подметил
RM
Но я все равно против класса, которые содержат много абстрактных методов, а потом от такого класса наследуется какая нибудь мелочь
RM
и потом когда ты к указателю такого объекта обращаешься, то весь геморрой выходит наружу
RM
и потом сиди думай что из этого, которое торчит наружу из подсказок IDE можно юзать для этого класса
RM
Да - да, такое тоже бывает
RM
А еще хуже если вызвав какой то из этих абстрактных методов ты ловишь краш
RM
Это означает, что ты не выиграл в лотерее индуса, который написал эти абстракции
RM
Короче, ООП не для школьников
RM
Ибо нужно строго соблюдать какой метод должен быть в верхушке абстракции
RM
Чтоб при наследовании не сломать ниче
RM
и не говнить список подсказок IDE
RM
Чтоб разработчик не тратил уйму времени копаясь в твоих говноабстракциях
RM
Тоже самое касается кучи синглтонов
RM
Я когда свой фреймворк писал в первый раз, то думал что это удобно