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