141–150 of 158 posts
The classic "Replace Conditional with Polymorphism" design pattern, which took me way to long to realize that it also applies to Python.
Yes, it's cataloged in Martin Fowler's excellent book Refactoring, Improving the Design of Existing Code in Chapter 9. I'd recommend the book strongly.
Reading the comments in this thread is very interesting to me, because each programmer seems certain of the superiority of his own programming style. We have some comments that disparage the change, saying that it obfuscates the code and makes it more difficult to understand. We have others saying that this change is a basic technique and it's "shocking" that the author wrote a book without this simple knowledge. Wha…
When people disagree that doesn't imply that the situation is highly subjective and all opinions are equally valid. In this case I believe they most certainly are not and I think you are drawing stronger conclusions than is warranted. There are objective ways in which to judge programming, by considering whether simple rules like the SOLID principles, low coupling, DRY, using composition over inheritance, keeping cod…
> There are objective ways in which to judge programming, by considering whether simple rules like the SOLID principles, low coupling, DRY, using composition over inheritance, keeping code complexity measurements low, favoring immutability, statelessness and referential transparency, etc. have been followed.
Hardly anyone on here would disagree that these are good programming practices (or so I think...), but the question becomes: what is the best way to favor immutability? FP solves that problem but many people don't like the all-or-nothing approach. Same with referential transparency.
> One can wonder what comments would be left if you removed all those from programmers with less than 5 years of programming experience, programmers under 30 and programmers with experience in only a single language.
Programmers under 30? Think how many languages exist that aren't even 30 years old! This is one area where I highly disagree. I have found that age matters very little with regard to someone's ability to write code. I have seen code written by "veteran programmers" that is worse than some teenager's weekend project. I'm not denying there is a correlation, but I would say it is a very weak correlation that probably isn't worth mentioning.
I do agree with programming experience, although I'll add the caveat that programming seems to be interesting compared to other subjects in that the rate at which different individuals become better at it seems to vary very dramatically.
Reading the comments in this thread is very interesting to me, because each programmer seems certain of the superiority of his own programming style. We have some comments that disparage the change, saying that it obfuscates the code and makes it more difficult to understand. We have others saying that this change is a basic technique and it's "shocking" that the author wrote a book without this simple knowledge. Wha…
When people disagree that doesn't imply that the situation is highly subjective and all opinions are equally valid. In this case I believe they most certainly are not and I think you are drawing stronger conclusions than is warranted. There are objective ways in which to judge programming, by considering whether simple rules like the SOLID principles, low coupling, DRY, using composition over inheritance, keeping cod…
A lot of folks drew attention to "You can reuse code with inheritance. Absolutely crazy. Brilliant." and took as equivalent to me saying "It's absolutely crazy and brilliant you can reuse code with inheritance." I get that both in- and especially out-of-context that's how it comes off, but it's not what I meant. It was sloppy and I should've been more careful in writing.
I meant it to come off more like "...everything is dynamic and decided at run-time, plus you get a great plugin architecture if you do some polymorphic tricks with these RowType objects. And all of these benefits came from just one simple refactoring. The power of small refactors is absolutely crazy. Brilliant." (I've added this as an addendum to the post)
Like the point of the whole thing wasn't about the refactor itself and if/how the code "rocked my world", but the fact that a refactor could have a seismic effect on the future of a project and the direction it takes.
The addition of many more row "types" wasn't even in the orbit of my thinking without the refactor, and it really helped shape where the project went: there were just those 4 branches in the `if`/`else` tree in this post, but there are now 20-odd default row configurations.
Hope that helps some folks to add more context
Earlier quoted context omitted.
== Programming sucks nowadays. There is not even a consensus on what is good in programming! Take a look at other professional cultures: people work extremely hard to develop the skills that everybody else in their profession have. What does a software developer do? Whatever they like on their own, there is no professional culture whatsoever: "Don't give a crap about the humankind's experience, I'll invent everything…
It's not that there's no professional culture in programming, it's that programming has a problem/solution space orders of magnitude larger than any other profession that has ever existed . If we could agree on some constraints of what software does and what the priorities are then we could develop more concrete professional standards, but that's not how it works. Software is the stuff of pure thought; it is layer up…
Earlier quoted context omitted.
So he didn't know some aspect of polymorphism. Is that pertinent to his book? It's not as if using if/else constructs is bad or wrong. In some fields of development it would be preferred, for blatant clarity. Does it follow that his book is bad or wrong because it was not written with understanding of this aspect of polymorphism?
"You can reuse code with inheritance. Absolutely crazy. Brilliant. All of this blew me away."
Earlier quoted context omitted.
Early in my career, a project manager said to me, "I've never heard one programmer praise another programmer's code. They always criticize!" I think that reinforced for me both that someone's approach might be good even if it isn't my own, and also that it's important to say when something is done well. Of course, there's also just a lot of bad code out there.... :-)
I spent a few years as the sole maintainer of a moderately complex enterprise app written prettly much entirely in PLSQL. Hundreds of thousands of lines of it. By the time I left a reasonable proportion of that was code I'd added. A few months after I'd left I got a phone call from the guy who'd taken over the project - he rang specifically to compliment me on the code and how easy it was for him to understand what w…
One of the great things about joining a well-written project is that usually I learn something new. If that guy was so struck by your code that he called you up, I bet he learned a few things, too.
As in the OP's story, sometimes the code I learn most from isn't immediately obvious, and I have to "go with it" for a bit before I see what's happening. But that takes some openness, perhaps something like what Zen folks call "beginner's mind."
There are times when, like you, I have to start tearing things out and rewriting chunks of functionality, but in general I think programmers are too quick to take that step. My PM anecdote taught me the importance of reading other folks' code charitably, really trying to understand why they made the choices they did, and doing my best to respect and follow their approach. Textual interpretation has the "principle of charity," and reading code probably should too.
Earlier quoted context omitted.
I don't believe that its terribly antiquated. Pretty much everything bases itself off of this book. Edit: drafted iPad - fixed spelling. Trilby - does anyone even use that word anymore?!?
It has a couple of patterns that have been more or less rejected by modern OO leaders: 1. "Singleton" (enough said) 2. "Template method" is more or less "inheritance over delegation" There's also a couple like Flyweight that are of such narrow applicability that they hardly merit placement on the short list with classics like Composites and Factories, and a few new items like Dependency Injection are surely worth a m…
Earlier quoted context omitted.
It has a couple of patterns that have been more or less rejected by modern OO leaders: 1. "Singleton" (enough said) 2. "Template method" is more or less "inheritance over delegation" There's also a couple like Flyweight that are of such narrow applicability that they hardly merit placement on the short list with classics like Composites and Factories, and a few new items like Dependency Injection are surely worth a m…
What is your recommended introduction to design patterns? I've been meaning to read the original but I do get that old-school clunky Java feel from it. I'd be very interested in an updated Design Patterns for OO languages with mild functional capabilities like C++11, C#, Python.