Of course, in theory this is true. In practice people tend to avoid ANY duplication no matter what. Especially junior developers, as if duplication would be the root of all evil.
We still need a way to track that there’s some common pattern in the code. So that when we update one pattern we wonder about the others places in code with the same pattern. Avoiding duplication doesn’t solve that
My metric for that is "does that code MEAN the same thing" or "does it just look the same". Has worked quite well for me so far. I frequently find myself making a copy of some code rather than adding a parameter (most commonly done with code that would get some flag added)
Me too ! I don't follow DRY that much, I'm aware that copy pasting is good enough for a few weeks / months to see how things evolve in the future, and do refactor when it's really needed. That said, how do you know if they mean different things ? For GUI code for example, they do mean the same thing, but there's a good chance the code will evolve in the future so premature refactor are wasted time
GUI code changes as fast as your GUI does. If you have two buttons, call makeButton twice. If they have totally different sizes, don't calculate the size inside makeButton. If tomorrow you want a button and a checkbox, don't call makeButton twice with isCheckbox=true the second time.
Fun fact: Win32 checkboxes are buttons with a bitflag that says they are actually checkboxes.
Mostly by looking at the calling site where the code is already used and the calling site where I want to reuse it. If both of those mean the same (calculate the tax on x products, for the purpose of applying to the shopping cart, vs for applying to generating reports) then I'll reuse it, if it can be achieved without adding stuff like flags, in most cases. In other cases, it just looks the same (sum some field + calculate a percentage of that, for example, for discounts vs taxes on products) where it's obvious that they don't mean the same. (Though, I do heavily rely on a good type system to deal with future evolutions of that copied code)
> when we update one pattern we wonder about the others places in code with the same pattern. Avoiding duplication doesn’t solve that
It can, that's all about how aggressively you factor and structure your code, eg. combinators make it easy to reuse code in different application patterns without rewriting.
This is something I've seen repeated time and time again as a criticism of (misused) abstraction and DRY, yet I've never seen ONCE -- and this is not hyperbole, I mean it literally -- a junior making an abstraction with any thought to reuse, generalizing anything, or caring about not repeating code. Most juniors I've worked with are content to just churn new code without paying attention to the codebase at all. This all before the AI deluge, mind you.
Very similar with patterns. I've often read people protesting that juniors overuse design patterns, yet I've seldom seen a junior (mis)use anything more complex than a singleton, and when they use any pattern, it's usually forced upon them by an opinionated Java framework.
This smells more like the fluidity of what people mean by “junior” more than anything else. Journeymen engineers in their over-engineering phase, or even very “senior” expert programmers can suffer over fitting the product to their own mental model. The most senior judgment is to understand when an abstraction makes sense at a customer level, because that defines the durability of a business-logic abstraction.
I do agree this happens with the senior overengineering phase, but the comment I replied to mentioned "especially juniors" and I've heard this trope specifically about juniors, with the implication they want to apply what they learned in college, but this hasn't been my experience at all.
I was working at that time and never saw this from juniors. Overeager seniors and architecture astronauts, sure. But juniors? They mostly copy pasted code without even taking a second look at the codebase, and without bothering to break functions in any sensible way.
Mind you, I mean enterprise and line of business software, not hobbyists. I also mean of their own volition, not the kind of nonsense that Java frameworks often forced on them (all the patterns under the rainbow, factory abstract method factory of abstract methods).
I was probably that guy! It was all the rage 20 years ago, including worrying about the diamond inheritance problem. What is the equivalent in the current generation? ORM that no one can maintain? Unnecessary dev ops complexity? Anything "web scale"?
Are ORMs still a thing? I've been away from OOP for some years now, but just when I was leaving it, there was a trend firmly against ORMs... my guess was that they were on their way out, replaced by more lightweight libs and frameworks? Or did they make a comeback?
Regarding OOP itself, I also remember when "favor composition over inheritance" became a thing. Was this reversed too?
I was very late to arrive to Java around 2015. This expression was wide-spread at the time. For those involved with "OOP" enterprise languages like .NET/C# or Java, when did "favor composition over inheritance" become dominant?
I love an ORM. I think much of the problems people experience with ORM, OOP, Restful routes, is because they get the domain model wrong. When you model the data correctly you don’t need to have complex queries that push ORM beyond their breaking point.
I think it's more complex than just about getting the domain model wrong. ORMs introduce tradeoffs and are inherently complex and full of caveats (both when deciding to use one or not), as amusingly pointed out in the much-discussed article from 2006: "[Object-Relational Mapping is] The Vietnam of Computer Science" [1]
----
[1] https://archive.is/QVPj (excuse the archive link, Ted Neward's blog seems now lost to linkrot).
No trolling: What langauge and what framework? One thing I can say from experience: I have seen some teams where they have deep knowledge of an ORM framework, and they are crazy productive when writing enterprise CRUD software.
I agree from my extensive experience writing enterprise CRUD software. At this point, inheritance is like a plague that no one wants to touch. The best examples that I have seen are abstract base classes with insanely restricted overrides. If writing Java, imagine all of the public/protected methods are final except one or two. Wherever possible, classes are intentionally final to avoid any inheritance. To make a joke: "That shit is locked down!"
> Very similar with patterns. I've often read people protesting that juniors overuse design patterns, yet I've seldom seen a junior (mis)use anything more complex than a singleton, and when they use any pattern, it's usually forced upon them by an opinionated Java framework.
I've seen it occasionally. There was one junior whose code I saw littered with DTO that're an exact copy of the business object and DAOs where every method is just a wrapper for a Hibernate method. But yeah it's rare.
Win32 checkboxes, radiobuttons and groupboxes are buttons with extra bitflags. What's the common denominator? They all have text and do something when you click on them. Except groupboxes, which don't do something when you click on them.
Were you the same when you were a junior? I was. I didn't have the experience to understand the impact of my changes. The norm reply on HN: "You need more mentoring or code review.". Sometimes (usually?) that is in short supply.
You raise a great point in your reply. At some point, as a junior, you begin to develop your own personal software philosophy and break-away from your seniors/mentors.
I have recently fallen into a job at a small company that really seems to have this culture. Thankfully, I'm only going to be here for a year and a half or so (fixed term job for working holiday visa), but I'm trying to be really aware of how its impacting my career development.
There is no automated testing, no meetings, seemingly no code review process, no standardization of schemas for files that are passed between different applications, all jobs are run on on prem desktop workstations.
And instead it gets replaced with the actual root of all evil, complexity.