Здравствуйте, maxkar, Вы писали:
M>Совсем забыл. Еще такой подход решает проблему комбинаторного взрыва. Если предусмотрено переопределение 50 функций, где-нибудь захочется переопределить какие-то две. В другом месте — другие три. А потом захочется поиметь все вместе. На явном переопределении это делается. При наследовании возникнут большие сложности. Еще хуже будет, если подобных групп несколько.
Мне кажется, это явная демонизация проблемы. В случае "захочется поиметь все вместе", во-первых, есть прямое решение; в терминах C++ это явный выбор необходимых реализаций в сводном потомке при том самом "виртуальном базовом" (кривоватом, но для простых случаев работающем). Во-вторых, а почему это вдруг облегчит что-то? Если B<-A, C<-A, D<-(B+C), то в D надо будет выписать все переопределения из B и C. Далее, если E<-D, F<-D, в них тоже надо будет выписать все эти переопределения, и так каждый раз... вы считаете такой вариант нереальным? Я как-то вижу вокруг себя его чаще.
So what does compression-oriented programming look like, and why is it efficient? Like a good compressor, I don’t reuse anything until I have at least two instances of it occurring. Many programmers don’t understand how important this is, and try to write “reusable” code right off the bat, but that is probably one of the biggest mistakes you can make. My mantra is, “make your code usable before you try to make it reusable”.
Similarly, like a magical globally optimizing compressor (which sadly PKZip isn’t), when you are presented with new places where a previously reused piece of code could be reused again, you make a decision: if the reusable code is already suitable, you just use it, but if it’s not, you decide whether or not you should modify how it works, or whether you should introduce a new layer on top of or underneath it.
Finally, the underlying assumption in all of this is, if you compress your code to a nice compact form, it is easy to read, because there’s a minimal amount of it, and the semantics tend to mirror the real “language” of the problem, because like a real language, those things that are expressed most often are given their own names and are used consistentl
These are all things that most programming methodologies claim to do in an abstract fashion (build UML diagrams, make class hierarchies, make systems of objects, etc.), but always fail to achieve, because the hard part of code is getting the details right. Starting from a place where the details don’t exist inevitably means you will forget or overlook something that will cause your plans to fail or lead to suboptimal results. Starting with the details and repeatedly compressing to arrive at the eventual architecture avoids all the pitfalls of trying to conceive the architecture ahead of time.
The fallacy of “object-oriented programming” is exactly that: that code is at all “object-oriented”. It isn’t. Code is procedurally oriented, and the “objects” are simply constructs that arise that allow procedures to be reused.
Здравствуйте, rusted, Вы писали:
R>Semantic Compression
Я помниться постил тут некоторое время назад свою "статью", где проводил параллели между рефакторингом и сжатием информации.
Рад, что эти мысли не только мне в голову пришли
Почему так получается, что когда код представляет из себя набор переменных, методов и операций, то такой код очень затруднителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке. И это даже при отсутствии злоупотребления операциями. С кодом написанным, что называется в ООП и ФП, таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться в полезности кода в лоб. Складывается впечатление, что код в лоб — это такой хорошо замаскированный современный код в лоб. И ещё я не понимаю, почему как только люди беруться за проект, то тут же как грибы после дождя начинают появляться GOTO. На самую простую функциональность количество порой приближается к сотни. И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?
Здравствуйте, -n1l-, Вы писали:
N>Почему так получается, что когда код представляет из себя набор переменных, методов и операций, то такой код очень затруднителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке. И это даже при отсутствии злоупотребления операциями. С кодом написанным, что называется в ООП и ФП, таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться в полезности кода в лоб. Складывается впечатление, что код в лоб — это такой хорошо замаскированный современный код в лоб. И ещё я не понимаю, почему как только люди беруться за проект, то тут же как грибы после дождя начинают появляться GOTO. На самую простую функциональность количество порой приближается к сотни. И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?
Есть иллюзия навроде "щас я добавлю строчку и все проблемы исчезнут". Эти иллюзии проходят с опытом, но только если человек положительно относится к обратной связи, если его не оскорбляет указание на баг в его коде.
То есть, что бы понять такие вещи, нужно исправлять код, расширять, переделывать, переписывать и смотреть на факты — время, качество и тд.
Здравствуйте, мыщъх, Вы писали:
>> в полезности ООП. Складывается впечатление, что ООП это такой хорошо >> замаскированный современный GOTO. И ещё я не понимаю, почему как только М>замаскированный GOTO это исключения.
