loading...

re: Elegant patterns in modern JavaScript: Ice Factory VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Thanks for taking the time to read and respond. In my experience, when it comes to a codebase that is intended to last and to grow; to paraphrase ...
 

I would also argue that overriding methods and magically changing behaviour is an anti-pattern.

Patterns and anti-patterns are mostly fads anyway, there are places for everything. The most important thing is what makes you efficient as a developer and your code better.

If your code becomes clearer, better, and you use less time by calling a "non-public" method, or by replacing a method in a class or similar, you should absolutely do so. I'll even go through a bit of effort with reflection etc. to make it possible to implement an easy and clear solution to the problem.

In fact, I see our entire industry moving toward immutability as a virtue

Well, this generally speaking is for data, and more specifically application state. Not your application code, libraries, and so on.

A developer who is consuming an object and does not have access to, or the ability to, alter the source of that object should never be altering its behaviour; that's just a recipe for disaster.

To me that sounds like you're the kind of person who likes languages with the private keyword. I don't. I hate languages with the private keyword (or really even protected).

I've found so many examples of libraries, frameworks, and just application code where someone used protected or private and that meant I had to write a massive hack, or copy & paste massive amounts of code to create a replacement, instead of just doing the thing that the developer initially didn't think was necessary.

One of the most common examples is just having a private cache, that you can't clear when you, as the user of the library/framework/code in general, know better than the original developer.

I've lost count of the amount of times I've cursed the developers who used private seem to have thought "I know better than anyone else who will ever use this code, so I'm going to stop them from doing these things".

I've similarly lost count of how many times I've seen a Python library use _ prefix on things that I actually needed so I can call them and I've thought "thanks for making that possible".

If an object's source needs to change, then it is the authors' responsibility to change it (and by author I mean the team responsible, not necessarily the exact individual who originally wore the code).

It's not quite often quite so easy. Some library published on GitHub, PyPI, NPM, etc. is not often quite as easy for you to patch (the developer just started a 3 year walkabout, but the library is used somewhere by your framework of choice, etc.) as it would be for you to patch the code if it's been properly written - with clear hints as to "if you touch these things you might break something", and for that the _ prefix to the name tends to be enough.

When it's your own code it's usually just a matter of a simple refactor to make a private method non-private to call it, extending to change the behavior, etc. .. your own code is rarely the problem, it's the other people who think they're better than anyone else ever can be and lock down their code as much as they can.

Thanks for taking the time to reply.

It's always instructive to read a different point of view. I think we may just have to agree to disagree on pretty much all of these points.

The behaviour you seem to be describing is exactly the sort of thing that I have seen lead to serious problems in many codebases over the years. Having said that, I can appreciate that my experience is certainly not the be-all and end-all when it comes to coding, and I have been around long enough to know that there is no such thing as never and always when it comes to coding and design, it's just a matter of trade-offs.

Thanks again for your insights.

Code of Conduct Report abuse