undefined | Better HN

0 pointspionar11y ago0 comments

Ok, let's say you have a class that performs some process - ProcessBase. It then needs to call Step1(), Step2(), and Step3() methods. I had a similar case a few months ago at work.

However in certain cases, you need to change what Step2() is, but not break up the process. You don't want outside callers to access Step2() directly, but you need a way to allow a subclass to define it's own Step2() while keeping the overall process intact.

So you would make those three methods protected (and, depending on language, virtual) and override as needed in a subclass.

That's the use case I've used protected for.

Also, I may want to do things internally inside my package/module/library that I want to be able to internally override, but not make it part of my API in case I want to change it later.

0 comments

1 comments · 1 top-level

Jweb_Guru11y ago

Here's what I don't understand: either you need to modify it within its own package (so you can use package-private to prevent anyone else from accessing it) or you have to leave it available for potentially anyone to modify, as you already are when you make it protected (hence: public). To be clear, I understand why people want protected. I'm just not sure it's strictly necessary from a permissions / invariants standpoint.

(Conversely, your scenario can be precisely solved without violating encapsulation by passing in step2 as a function, and passing in any information it requires as parameters. I suspect most of the usecases for protected go away with first-class functions).

j / k navigate · click thread line to collapse