I found the idea of "compression oriented programming" as Casey called it kind of interesting.
The basic Idea as I understand it is "write for your current use-case, then generalize, abstract and extract functions when you find yourself repeating yourself, growing functions to and unwieldy size, etc."
But my results with trying to use it are a little bit mixed. I feel like I'm progressing a little faster but I keep touching and moving the same code over and over again. Also, I find myself to produce somewhat more sloppy code, since I naturally seem to fall into a mindset of "just keep moving".
I introduce structures, delete them again, merge and split structs all the time when doing this, so it feels to me that a larger part of the code-base is in-flux at all times. The process after a while becomes "write a specialized version of a new feature that let's you immediately test it" then "need a slight variations of different parts of it" becomes "distribute the code into the various structs and that it belongs to". Maybe I'm not doing the "compression" step quite right, since I feel like my initial "compression" is not strong enough, since I end up with questionable data-flow of having larger parameter-lists or returning non-intuitive return values.
Is this just a question of experience with the approach and missing discipline on my part? Or are there some useful heuristics that I'm missing like "if you touched it twice already, stop and think about it for a while" or something like it.
The basic Idea as I understand it is "write for your current use-case, then generalize, abstract and extract functions when you find yourself repeating yourself, growing functions to and unwieldy size, etc."
But my results with trying to use it are a little bit mixed. I feel like I'm progressing a little faster but I keep touching and moving the same code over and over again. Also, I find myself to produce somewhat more sloppy code, since I naturally seem to fall into a mindset of "just keep moving".
I introduce structures, delete them again, merge and split structs all the time when doing this, so it feels to me that a larger part of the code-base is in-flux at all times. The process after a while becomes "write a specialized version of a new feature that let's you immediately test it" then "need a slight variations of different parts of it" becomes "distribute the code into the various structs and that it belongs to". Maybe I'm not doing the "compression" step quite right, since I feel like my initial "compression" is not strong enough, since I end up with questionable data-flow of having larger parameter-lists or returning non-intuitive return values.
Is this just a question of experience with the approach and missing discipline on my part? Or are there some useful heuristics that I'm missing like "if you touched it twice already, stop and think about it for a while" or something like it.
It's kind of hard to say without actually watching you program :) But yes, it sounds like you maybe just need to improve the set of techniques you are using in the compression step so that you are not producing code that makes you uncomfortable...
- Casey
- Casey
I know that Casey very deliberately does not call C.O.P. "refactoring" due to the OOP baggage that term has accumulated in the industry, but there is quite a bit of conceptual overlap. If you're feeling a little shaky on your technique, there's a lot of refactoring literature out there that might point to some ways to start to improve it. Martin Fowler's "Refactoring" is, in spite of its OO bent, a really solid text. It's not perfect, and hopefully Casey isn't offended that I'd recommend it in relation to C.O.P., but I think you could do a lot worse than to check it out and see if it helps!
Some of the refactorings in Fowler is quite offensive to the non-OOP brainwashee such as taking a switch-statement and turning it into a polymorhic class for each case inheriting from an interface. Like that would improve your code :)
Other refactorings are more useful, such as pulling out code into separate functions and the mechanics for that, or replacing magic numbers with named constants. Seeing that it's Java-based, it of course has to deal with a lot of questionable idioms.
Overall it has some nice stuff in it, but you should only take it as a demonstration of different ways to structure pieces of code, not a guiding compass on what is good code.
Other refactorings are more useful, such as pulling out code into separate functions and the mechanics for that, or replacing magic numbers with named constants. Seeing that it's Java-based, it of course has to deal with a lot of questionable idioms.
Overall it has some nice stuff in it, but you should only take it as a demonstration of different ways to structure pieces of code, not a guiding compass on what is good code.
I'll take a look at the book.
And to just to be clear I was a devotee of the OOP stuff, most of the formal education I got was Java related. But luckily I was also taught C++ among others. I took a liking to C++.
I was once tasked to adapt a physics library to an existing piece of simulation software that used another library. You don't want to see the over-designed mess I had. I had multiple Inheritance for every physics type and I not only called a virtual method on every physics step on every physics entity but I was doing a dynamic-cast each and every time. I had a fucking beautiful UML Diagram though.
That doesn't mean I am now religiously "anti all things OOP", I just think that it's a little overused. I'm also not quite as averse to using libraries as Casey is and I like to use the C++ standard library quite a bit (with the exception of when I want to write re-usable libraries, which Casey did for a long time I assume, so while I understand his caution I'm not matching it in all cases). Also, yeah even in the small game I am developing now for test purposes I have polymorphic classes with virtual methods for the game-states. I know that one or two virtual calls per frame aren't going to kill me and have the potential to not make me have to add another "case" each time.
I'm just wary of overusing it, I want to have learned something from my mistakes. Might it be that I'm sometimes a little too cautious around OOP? Sure. But I don't prop it up like some boogeyman, I'm like to use it as just one of the tools in my belt instead of using it as a hammer to screw in screw.
And to just to be clear I was a devotee of the OOP stuff, most of the formal education I got was Java related. But luckily I was also taught C++ among others. I took a liking to C++.
I was once tasked to adapt a physics library to an existing piece of simulation software that used another library. You don't want to see the over-designed mess I had. I had multiple Inheritance for every physics type and I not only called a virtual method on every physics step on every physics entity but I was doing a dynamic-cast each and every time. I had a fucking beautiful UML Diagram though.
That doesn't mean I am now religiously "anti all things OOP", I just think that it's a little overused. I'm also not quite as averse to using libraries as Casey is and I like to use the C++ standard library quite a bit (with the exception of when I want to write re-usable libraries, which Casey did for a long time I assume, so while I understand his caution I'm not matching it in all cases). Also, yeah even in the small game I am developing now for test purposes I have polymorphic classes with virtual methods for the game-states. I know that one or two virtual calls per frame aren't going to kill me and have the potential to not make me have to add another "case" each time.
I'm just wary of overusing it, I want to have learned something from my mistakes. Might it be that I'm sometimes a little too cautious around OOP? Sure. But I don't prop it up like some boogeyman, I'm like to use it as just one of the tools in my belt instead of using it as a hammer to screw in screw.
Edited by Bigpet
on
Bigpet
I'm like to use it as just one of the tools in my belt instead of using it as a hammer to screw in screw.
That's the perfect attitude to have for pretty much anything programming-related :) Most popular techniques exist because they were the right answer to *something*, the problems only arise when other people want to try to make them the right answer to *everything*.