Looking at Internal Methods

Looking at internal Methods

You want methods() for an S3 generic such as str():

> methods(str)
[1] str.data.frame* str.Date*       str.default*   
[4] str.dendrogram* str.logLik*     str.POSIXt*    

   Non-visible functions are asterisked

Using getAnywhere(str) is not really helpful because str() is visible so you get the same result if you just run str at the prompt. You need getAnywhere() to look at the hidden methods listed above:

getAnywhere(str.default)

for example.

Shame you need to know what kind of generic a function is to list the methods; seems user-friendliness would be improved if R didn't care what kind of method type was supplied to one or other of these functions.

Why do i have access to internal methods outside of the namespace?

As per the documentation internal (C# Reference)

Internal types or members are accessible only within files in
the same assembly

As per your comment

[It's] difficult to design a way to hide these functions but still give
access to a specific class.

The standard access modifiers are fairly limited, you would need put the calling code in the same assembly to use internal. Additionally there is no way to grant an access list for calling classes unless you do this at runtime.

However, you could use an Explicit Interface Implementation. This will not completely limit access, but it will make it so you need to explicitly ask for it, and hides it any other time.

public interface IGrid
{
    Vector2Int ToGrid(...);
}

public abstract class Grid : IGrid
{
   Vector2Int IGrid.ToGrid(...) {}
}

Usage

var rectGrid = new RectGrid();
((IGrid)rectGrid).ToGrid(); // you need to explicitly cast to the interface

public vs. internal methods on an internal class

The internal class Foo declaration will override the accessibility of the public void Fee() method, effectively making it internal.

In this case, using internal vs. public on the methods will have the same effect. The only reason I would choose public methods vs. internal methods in a case like this would be to ease transitioning to a public class in a future version, should you choose to do so.

C# Calling internal methods of an object passed as interface

The whole point of interfaces is to show the abilities of the implementation. If you need to access internal members of the implementation, you should let the consumers of the code know they are not really internal (either by following the other answers here, or for example with Interface Segregation and passing around only individual role interfaces), or keep them really internal. In your case I think it should be encapsulated in the FooBase class.

I suppose that the DoSomething method also does other things to the IFoo implementation. Whatever Bar does with the internal type returned from the internal method should probably happen in FooBase in one of those other IFoo methods instead. The guiding principle here is Tell, don't ask.

internal methods and data structures .

No, unless the type (with the protected member) is itself internal. Internal types cannot be part of a public/protected API, as the consumer would have no way of using it.

You could, however, consider using a public interface to abstract the type - i.e.

public interface IFoo {}
internal class Foo : IFoo {}
public class Bar {
    protected void Test(IFoo foo) {}
}

Generics can be useful for this too:

protected void Test<T>(T foo) where T : IFoo { }

Calling internal methods in Medium Trust

I don't see a way to call it. The .NET security/trust model is designed to prevent exactly this sort of thing. If you could somehow circumvent it, you would have to file a security bug with Microsoft which would then (hopefully) be fixed and make your solution useless again ;-)

Can't you negotiate a higher trust level with the deployer/operator of your solution?

Are (a lot of) internal methods avoidable? (interface, factory pattern)

The factory pattern makes sense for polymorphism. That means that, for example, we want an IDialog and we don't care what the implementation is. We don't want to know. That way our code depends on IDialog and isn't coupled to any particular class that implements it.

If you're trying to do this:

dialog.CreateDialog("name").AddNameResponse(turnContext, profile, value);

...and the error is that whatever gets returned from dialog.CreateDialog("name") doesn't have a AddNameResponse method, that reveals that your code depends on some more specific class than what is returned from the factory.

The factory won't reduce coupling for a few reasons:

• Your code still depends on NameDialog. You need that exact class with its AddNameResponse method.
• Even if the factory returned that exact class, now you're coupled to the factory and that class.

It makes sense that you'd want to reduce the coupling, because if a class is tied to NameDialog it's also tied to ProfileService. It's impossible to test a class that depends on NameDialog without also depending on ProfileService.

The potential solutions will involve changing classes that depend on NameDialog. Here are few thoughts:

• Define an abstraction (such as an interface or a delegate) that describes what your class needs to do with NameDialog. Inject that into your class. Now your class depends on the abstraction, not the concrete class.
• If NameDialog does something really simple, perhaps you can inject it instead of an abstraction, and a better fix is to define an abstraction that represents ProfileService and inject that into NameDialog.
• Possibly do both.

What each of these mean is that you're

• Avoiding coupling by depending on abstractions
• Giving your dependency injection/IoC container the responsibility of creating objects

That will work better than combining creation of all those objects into a single factory. That approach would only make sense if any object returned by the factory is substitutable for any other type - you don't need to know what the concrete type is.

---

Related Topics