类直接调用自定义Error类是否违反SOLID原则？

你给出的代码在功能层面可正常运行，不存在语法或逻辑错误，但从SOLID原则对可测试性、可维护性的要求来看，直接在Class1内部实例化ErrorClass存在两处明显的可优化点：

• 强耦合了Class1和ErrorClass的实现，若后续需要替换统一的错误类实现（比如新增错误自动上报、堆栈格式化逻辑的新错误类），必须逐个修改所有直接实例化ErrorClass的业务类，改动成本极高
• 单元测试阶段无法验证异常抛出逻辑：你无法在测试中MockErrorClass来确认异常的入参、实例类型是否符合预期

是否要做依赖注入可以根据ErrorClass的定位灵活判断，不需要教条遵守SOLID原则做过度设计：

• 若ErrorClass是纯数据结构类，不存在任何可变外部依赖、也没有后续替换实现的需求，完全可以直接实例化，不需要额外做依赖注入
• 若ErrorClass本身包含业务逻辑（比如自动上报错误、格式化多语言错误描述等）、或者后续有替换实现的规划，就需要通过依赖注入解耦

如果确实需要注入多个错误类或其他依赖，可以通过以下方案规避构造函数参数过多的问题：

• 接入依赖注入容器统一管理所有依赖实例，不需要你手动在实例化Class1的时候逐个传入依赖
• 将同类型的依赖聚合为工厂类传入：比如创建ErrorFactory类，内部封装所有错误类的实例化逻辑，对外提供getUserError()、getAuthError()等方法，你只需要注入一个工厂实例，就可以在Class1内部获取所有需要的错误类实例
• TypeScript项目可以使用属性注入配合装饰器实现依赖自动注入，不需要将依赖列在构造函数参数中

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