Tyмблep (22.07.2024 20:10, просмотров: 63) ответил mse homjak на Вы полюбому напишете эти процэдуры с параметрами, в том или ином
виде.-
- Ну? Я-жэ и говорю:"жмёшь кнопку, мешок на спине, жмёшь другую, спина в мыле". mse homjak(138 знак., 22.07.2024 20:55)
- Бывает. У меня именно так. Без всех этих огромных (но бесполезных)
надстроек. Cкpипaч(323 знак., 22.07.2024 20:19)
- Что бывает ? Tyмблep(194 знак., 22.07.2024 20:22)
- Бывает - "типа крекс-фекс-пекс - и готово". Cкpипaч(152 знак., 22.07.2024 20:32)
- Если речь идет о написании нового кода, а не подгонки старого, то
ООП, в целом, выигрывает на любом уровне сложности. Точнее, она
ничем не хуже по затратам по сравнению с обычным программирования,
но более надежна и модернизируема. Вы можете писать в стиле ООП, не "включая" ООП, а при необходимости легко перейти -
"включить". Вам не надо переписывать код. Единственное ограничение
сегодня, это возможности компилятора. - Anvar(23.07.2024 06:37)
- ООП, с моей колокольни, это лишние абстракции и лишний текст, в
сравнении с модульным программированием. Избыточность +
спагетти-код, в его обьектной реинкарнации. Оно не может
выигрывать. Cкpипaч(269 знак., 23.07.2024 08:12)
- Модуль работы с периферией на ООП несущественно сложнее обычного
модуля. Его небольшое усложнение с лихвой окупается надежностью
кода из за абстракции данных и методов для пользователя - он ничего
не может сломать. А все эти наследования, полиморфизм это уже
дополнительные плюшки, которые не обязательны - Anvar(23.07.2024 09:08)
- Ключевое "для пользователя". Т.е. для человека, который получил это
в готовом виде, написанное, отлажэнное и документированное. mse homjak(146 знак., 23.07.2024 10:56)
- Можно подумать на неООП этого делать не надо - Anvar(23.07.2024 11:09)
- Именно, что надо. У чом выигрыш-то? Если нет перспективы хотя-бы двухкратного использования, имеем дурную работу. Да и дажэ для двух-трёх раз заморачиваться, такое себе. Это всё прекрасно, когда тебе дали на блюдечке с каёмочкой и ты его юзаешь налево-направо, как в каком Винтеле. Там ООП безальтернативен и писать мегапроги можэт туловище, не знающее чем триггер отличается от триппера. mse homjak(179 знак., 23.07.2024 12:17)
- Можно подумать на неООП этого делать не надо - Anvar(23.07.2024 11:09)
- Темплейты, иерархия классов, полиморфизм? Нет, я сам умею писать на Паскале для компилятора С++ (и будет несложно), но в чистом эксперименте - радикально сложнее. - Cкpипaч(23.07.2024 10:43)
- Ключевое "для пользователя". Т.е. для человека, который получил это
в готовом виде, написанное, отлажэнное и документированное. mse homjak(146 знак., 23.07.2024 10:56)
- Модуль работы с периферией на ООП несущественно сложнее обычного
модуля. Его небольшое усложнение с лихвой окупается надежностью
кода из за абстракции данных и методов для пользователя - он ничего
не может сломать. А все эти наследования, полиморфизм это уже
дополнительные плюшки, которые не обязательны - Anvar(23.07.2024 09:08)
- ООП, с моей колокольни, это лишние абстракции и лишний текст, в
сравнении с модульным программированием. Избыточность +
спагетти-код, в его обьектной реинкарнации. Оно не может
выигрывать. Cкpипaч(269 знак., 23.07.2024 08:12)
- Если речь идет о написании нового кода, а не подгонки старого, то
ООП, в целом, выигрывает на любом уровне сложности. Точнее, она
ничем не хуже по затратам по сравнению с обычным программирования,
но более надежна и модернизируема. Вы можете писать в стиле ООП, не "включая" ООП, а при необходимости легко перейти -
"включить". Вам не надо переписывать код. Единственное ограничение
сегодня, это возможности компилятора. - Anvar(23.07.2024 06:37)
- Бывает - "типа крекс-фекс-пекс - и готово". Cкpипaч(152 знак., 22.07.2024 20:32)
- Что бывает ? Tyмблep(194 знак., 22.07.2024 20:22)