In many languages there is a scope that is just less than public called internal.

Wondering, Why none of the language, implemented a feature on internal such that one can specify

  • Only what other classes are permitted to access or
  • Accessible to all classes in the module

There are many examples where a group of class works together as a concept, while only one or few classes are really needs to be accessed by other concepts in the system. Which means, if I could make some low level classes only available to the group of classes handling the concept, then that way I could prevent it from widely available to the entire module. Which also means those classes becomes encapsulated behind my higher level classes, in turn less coupling points in the design.

Is this feature available in any language?

  • 1
    You mean like C++'s friend modifier? – Kayaman Aug 26 '19 at 11:31
  • Can i say with friend that only classA and classB is allowed to access this class, in a 50 class module? – Saran Aug 26 '19 at 11:33
  • Yes, it provides fine grained access control, so you can (have to) manually specify the class names that get access. Examples here. I'm not aware of other (newer) languages that have that functionality though, maybe it was seen as unnecessary since you can usually design the modules/packages so that other visibility modifiers are enough. – Kayaman Aug 26 '19 at 11:46

This is exactly how access restriction works in Eiffel. In Eiffel, instead of a small number of coarse-grained access-levels like public, protected, package private, private, internal, etc. the class can specify for each member the precise list of other classes that should have access to this member.

For example, an export clause in an Eiffel class definition might look something like this:

    {NONE}        -- to nobody …
        all       -- … export everything (in other words, make everything private)
    {LINKED_LIST} -- to the class `LINKED_LIST`
        remove    -- export these two
    {ANY}         -- to all classes
        for_each  -- export the routine `for_each`
| improve this answer | |

Based on this it seems other languages have not been keen on implementing C++'s concept of friend classes/functions.

I don't know whether the suggested reason (friend breaks encapsulation) is a valid reason that would make "friend considered harmful", but as it seems to be missing from most languages it certainly isn't essential in making your design work. For example Java's package private (default) visibility could be used to imitate friend functionality, by keeping "friends" in the same package.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.