loading...

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

FULL DISCUSSION
 

I don't get this fear people have about their code being magically changed via prototypes, or by someone overriding the method.

Why is the acceptable solution not simply: "don't"?

Do you just accept anyone to edit your codebase as they wish and release everything to production without looking? Of course not.

On the other hand, overriding methods and magically changing your code can be super helpful in e.g. unit testing - e.g. make an internal method return a static response to trigger a special case that you might want to test.

So to me this stuff always smells a bit, and sounds like you're trying super hard to make your code more "safe" for literally 0 gains, while shooting yourself in the foot.

E.g. in Python convention is pretty much all that's needed - prefix your "private" methods with _ and people know they shouldn't be calling them if they don't know what they're doing. If they DO know what they're doing better than you did when you wrote the code (nobody is perfect, so this is bound to happen every now and then), they're going to be super annoyed if you went through massive amounts of effort to block them from doing so in your paranoia.

There is basically one case where I would consider an approach like that - when providing libraries to 3rd parties. Even then I'd have to have a pretty good justification beyond just "it's a library" to go through the effort.

 

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 Murphy's law, whatever can happen will happen. This tends to be true regardless of what standards, conventions, or policies are put in place.

I would also argue that overriding methods and magically changing behaviour is an anti-pattern. When it comes to unit testing, if we need to change the behaviour of some dependency we should use a mock. If there is no way to inject the mock, we probably have a design problem.

I also don't see how making objects less mutable provides "0 gains". In fact, I see our entire industry moving toward immutability as a virtue because the greatest source of bugs is unexpected and uncontrolled change.

I'm also not sure I understand what you mean by:

people know they shouldn't be calling them if they don't know what they're doing. If they DO know what they're doing better than you did when you wrote the code (nobody is perfect, so this is bound to happen every now and then), they're going to be super annoyed if you went through massive amounts of effort to block them from doing so in your paranoia.

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). 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.

There are many patterns for extending an object's behaviour that do not require changing the object itself.

 

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