What is the use of methods with an "inter-ternal" modifier?

Question

In what situation I would use a modifier method internal? There is a specific reason for this, namely where a public or private does not answer or does not answer?

That’s what I got here.

internal void MostrarCadastroFornecedor(string pastrNuCPFCNPJ, int paintWucChamador)
        {
            //Declarações
            ENTDBCORPFornecedor ventCorpFornecedor = null;
...................
}

Answer 1

I imagine you know what it’s for. If not, I replied about it in that reply (is VB.NET but it’s the same thing). In short, it determines that that type or member has visibility on the entire compilation unit, the Assembly.

Many believe that the default for types when nothing is used is private but it’s actually internal. For members the most common is the private even (except in enumerations and interfaces, since it makes little sense to have something private in these types).

You use it whenever you want to allow other related types to access this type or member but you don’t want the entire application to access it. So determine what should enter a Assembly is important.

What is private is what is in your room, is yours alone. What is public is what is available to everyone, that there is no restriction. And what is internal is what is available for your entire home, is not your private, but is private of your family.

Types

If we are talking about a type means that this type (a class, structure, enumeration, etc.) can only be accessed within the Assembly. It’s like he’s a private of Assembly. But not to be confused with private even if it only makes sense if one guy is inside another guy, then this one private indicates that this internal type can only be accessed within the type that contains it.

It is usually used for classes and other auxiliary types that are only needed to facilitate something that is within this Assembly. You isolate these types since they do not need or even should not be accessed by the application directly. Often used if you use component-based programming, where these components cooperate with each other.

Remember that a class should only have one responsibility. Then you can split an operation into several classes. But not all of them need to be accessed by the application, the others serve as helpers for the public classes. So classes with internal visibility are used when you have more complex solutions.

In some cases they can be used for code obfuscation and hinder improper access.

Members

For all purposes a member internal is a public, you should treat it as something that can be accessed outside the class. Only it’s something public with restrictions.

It should be avoided whenever possible in a member, as well as the public should be avoided. Avoiding does not mean not using, it just means that you should only use it if you are sure that this visibility is necessary for some reason. Always use as little visibility as possible, that is, if possible, use private. Some people consider it a mistake to use the internal as default, should be private.

Note that a member public of a kind internal is inherently internal. A member cannot have greater visibility than his type.

You may want to expose certain members to other components of a DAL, a ORM that are important for internal manipulation, but these members should not appear publicly in the model exposed for the entire application. This is just one example.

Some people consider that this visibility is used more than it should.

Frameworks often use it since they are intricate technologies and much depends among their members. If you browse through the sources from . NET you will see that it is used quite often. There it makes a lot of sense, but it is less common in "normal applications".

Your example

Take a test and try to access this method in a Assembly different. Can’t. See if this method is called in some other type. If it is not called, maybe you can change it to private. I say perhaps because in the future you may need it. But by his name, it seems to me that he is needed at other points.

Looking at the rest of the code it seems to have been written by those who don’t understand much how the language works and end up doing unnecessary things, so I wonder if this method should be internal same. I can’t say anything without seeing the whole. An example of unnecessary things:

ENTDBCORPFornecedor ventCorpFornecedor = null;

could be written only as:

ENTDBCORPFornecedor ventCorpFornecedor;

without prejudice.

One can say that it also does not cause harm, it makes more explicit. But for what? I might be better still, I probably would have done so (I don’t know if it’s possible since I haven’t seen the whole code:

var ventCorpFornecedor = new ENTDBCORPFornecedor();

I say all this because if you have something unnecessary, you can have other things.

Extra

What many people don’t know is that it’s possible to make something internal for a Assembly different from what a type is defined. This is done with a attribute:

[InternalsVisibleTo("OutroAssembly")]

Completion

Don’t worry about performance. It’s just a matter of code organization.

If you have something with a lot internal until it is well. It would be worse if there was exaggeration of public. Of course in many cases some of these internal would be better as private. But in general, if only one person works with that Assembly, it is more difficult to cause problems. The programmer can have the discipline not to use things of another kind improperly.

But note that a system that has very kind internal may only be making explicit what was already defined by default.

Already members internal are rarely good things, unless you have a very strong reason for it. Just as public not a good thing. But everyone understands when a public is necessary. When you are thinking of putting a visibility, always try first private which is the default for members in most cases. If not, think about protected to allow a derived class to access this member. If other related classes need this access, use internal. If in addition this classes derived in other assemblies need to access the member use protected internal and if you need access to a Assembly use the attribute cited above. And only if none of this is possible and needs more free access should you "opt" for public.

Answer 2

It would be used when you want the method to be used only by classes declared in the same Assembly, similar to internal class.

There is also the protected internal, that allows any class in the same Assembly to access the method (or attribute) as well as derivative classes in different assemblies.

I cannot imagine a situation that justifies these modifiers. I believe they are more related to RAD, simplifying some tasks or structuring the code.

Reference:

Access Modifiers (C# Programming Guide)