Мой подход. Ядро - Движок. - страница 136
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ну если я не публикую ничего большого, это не говорит что у меня нет ничего большого. Просто я делюсь только мелочами.
Ты удивишься, но у меня тоже был момент, когда я начал захлебываться в процедурном стиле. Как раз, когда впервые начал разработку GUI. Через несколько месяцев работы, код вырос и запутался настолько, что я уже не мог его развивать. Это был тупик.
Однако, тогда я придумал свой подход. Создать ядро, а вокруг него движок, - то есть код, который с ним работает. И все пошло на лад.
Поэтому, мой подход - это не процедурный стиль, как ты думаешь.
А ООП я пробывал. В какой то момент мне понравилось. Но только до момента, когда я увидел откровенные и бесмысленные изголения с кодом. Я понял, что мне просто крутят мозги и начал съезжать с него.
Там было много лишнего. Классификация ради классификации, дробление кода ради дробления, оборачивание кода ради оборачивания... Все это не вязалось с рациональной необходимостью, которую требуют механизмы. Поэтому, я начал отдолятся от ООП.
Там было много лишнего. Классификация ради классификации, дробление кода ради дробления... Все это не вязалось с рациональной необходимостью, которую требуют механизмы. Поэтому, я начал отдолятся от ООП.
Бред!
Увы, не бред.
Рисование на канвасе не требует обертки в виде класса. Список функций достаточно. Никакие права доступа к методам не нужны тебе чтобы рисовать. И ты это знаешь. Но ты отрицаешь этот факт. Отрицаешь очевидное.
Бред!
Ничего подобного. Рассуждаю исходя из простой логики.
Зачем тебе создавать объекты при обращении к функциям класса, если к ним можно напрямую обратиться?
Я понимаю, если у тебя гигантская и запутанная система классов. Но ты ее не создал, а все равно используешь обращение к функциям через объекты. Зачем?
Где практическая необходимость? Ее нет. Есть абстрактная вера в то, что так нужно, и все.
Увы, не бред.
Рисование на канвасе не требует обертки в виде класса. Список функций достаточно. Никакие права доступа к методам не нужны тебе чтобы рисовать. И ты это знаешь. Но ты отрицаешь этот факт. Отрицаешь очевидное.
Ничего подобного. Рассуждаю исходя из простой логики.
Зачем тебе создавать объекты при обращении к функциям класса, если к ним можно напрямую обратиться?
Я понимаю, если у тебя гигантская и запутанная система классов. Но ты ее не создал, а все равно используешь обращение к функциям через объекты. Зачем?
Где практическая необходимость? Ее нет. Есть абстрактная вера в то, что так нужно, и все.
Мне только не надо эту ахинею рассказывать. Вряд ли на этом форуме найдется хоть один человек, который мог бы учить меня канвасу ( к сожалению..., Был бы рад оказаться не правым)
Ну, тут не много таких людей. Я наверное, один из них. Хотя, не учить тебя моя цель. А только услышать вразумительный ответ. Зачем при рисовании обращатся к функциям класса через объекты, если ты пользуешься всего ОДНИМ классом?
Зачем при рисовании использовать обращение к функциям класса через объекты, если ты пользуешься всего ОДНИМ классом?
переведи
Ты работаешь с классом CCanvas. Он один в твоей разработке.
Класс, это часть системы. Если он ОДИН, то системы нет.
Тогда зачем создавать объекты класса и обращаться к его функциям по правилам ООП?
Тебе ПРАКТИЧЕСКИ не нужен ООП в работе с ОДНИМ классом.
Но, ты используешь ООП в работе с ОДНИМ классом. Хотя это НОНСЕНС.
Ты работаешь с классом CCanvas. Он один в твоей разработке.
Класс, это часть системы. Если он ОДИН, то системы нет.
Тогда зачем создавать объекты класса и обращаться к его функциям по правилам ООП?
Тебе ПРАКТИЧЕСКИ не нужен ООП в работе с ОДНИМ классом.