如何让.NET游戏的internal类对所有外部程序集可访问？

一、直接把所有类改public的利弊 #

• 好处：最省事，Mod开发者不用搞额外配置，直接就能引用调用，门槛极低。
• 问题：
  • 彻底打破原本的代码封装，那些internal类里的内部逻辑可能根本没考虑过对外暴露，Mod依赖这些不稳定的实现后，游戏版本一更新，Mod大概率会崩。
  • 给自己挖坑，以后改这些类的结构都得顾及Mod兼容性，游戏本身的迭代空间被压缩。

二、更靠谱的替代方案 #

1. 只公开Mod真正需要的核心接口 #

别一股脑全改，先梳理清楚Mod要用到哪些功能，给这些功能写明确的public接口，让原internal类去实现这些接口，然后只把接口暴露给Mod。

// 给Mod用的公开接口
public interface IGamePlayer
{
    int GetHealth();
    void SetHealth(int value);
}

// 原来的internal类，实现接口
internal class Player : IGamePlayer
{
    internal int Health { get; set; }

    public int GetHealth() => Health;
    public void SetHealth(int value) => Health = value;
}

这样既满足Mod需求，又保住了内部类的封装性，只要接口不变，游戏内部怎么改都不影响Mod。

2. 用适配器做中间层 #

写专门的public适配器类，作为Mod和游戏内部类的桥梁。适配器负责调用internal类的逻辑，对外给Mod提供稳定的方法。

// 对外公开的适配器
public class PlayerAdapter
{
    private readonly Player _player;

    public PlayerAdapter(Player player)
    {
        _player = player;
    }

    public int GetHealth() => _player.Health;
    public void Heal(int amount) => _player.Health += amount;
}

Mod只跟适配器打交道，游戏内部类改了，只需要调整适配器就行，不用暴露内部细节。

3. 条件编译灵活控制权限 #

加个编译符号，只有在构建供Mod开发用的SDK版本时，才把需要的类改成public，正式游戏版本还是保持internal。

#if MOD_API
public
#endif
class Player
{
    // 类内容
}

编译正式版时用默认配置，编译SDK时开MOD_API符号，自动切换访问权限，两头都顾到。

4. 优化Friend Assemblies的用法 #

之前觉得Friend Assemblies不合适？可以换个思路：做一个专门的Mod SDK程序集，把它设为游戏程序集的友元。Mod开发者只需要引用这个SDK，SDK内部去调用游戏的internal类。这样不用公开所有类，还能集中控制哪些功能能被Mod访问。

三、总结 #

全量改public虽然快，但长期来看隐患不小。更推荐针对性公开接口或者用适配器模式，既能满足Mod开发，又能保住代码封装性，给游戏后续迭代留足空间。要是赶进度，条件编译也是个不错的折中办法。

内容的提问来源于stack exchange，提问作者Anikyte