-
5 votesanswersviews
门面模式与SRP
在经典的Facade模式中，单个对象通常为更复杂的东西提供简化的界面 . 正如四人帮所说的那样（尽管接近“官方”......）： Facade（185）为子系统中的一组接口提供统一接口 . Facade定义了一个更高级别的接口，使子系统更易于使用 . 和 ...外观只是将子系统对象的接口抽象化，使其更易于使用;它没有定义任何新功能，子系统类也不知道它 . 或者，正如Unmesh将其放入h... -
0 votesanswersviews
在业务层中反转控制和注入数据层依赖性
我们正在.net / c＃中设计一个分层业务应用程序，我们正在尝试按照我们认为合适的方式遵循SOLID原则 . 可测试性在我们的项目中非常重要，为此我们使用Moq . 除了其他方面，我们使用moq来模拟我们的实体框架上下文 . 由于我们测试的主要目标是主业务层（BL）逻辑，因此可以使用数据访问层（DAL）上下文注入业务层类 . 见下面的例子 . 负责加载数据的BL类的示例构造函数 . 此类注入用于... -
1 votesanswersviews
开放封闭原则 - 重构以基于新功能创建基类
因此，当编写原始代码时，只需要说LabTest类 . 但现在说我们有新的要求添加说RadiologyTest，EKGTest等 . 这些类有很多共同之处，因此有一个基类是有意义的 . 但这意味着必须修改LabTest类，让我们说它的界面将保持原样，换句话说，LabTest类的消费者不需要改变 . 这违反了开放封闭原则吗？ （正在修改LabTest） . -
39 votesanswersviews
依赖性倒置原则（SOLID）与封装（OOP的支柱）
我最近讨论了依赖性倒置原则，控制反转和依赖注入 . 关于这个主题，我们一直在争论这些原则是否违反了OOP的一个支柱，即封装 . 我对这些事情的理解是： Dependency Inversion Principle 暗示对象应该依赖于抽象，而不是结核 - 这是实现控制反转模式和依赖注入的基本原则 . Inversion of Control 是依赖性倒置原则的模式实现，其中抽象依赖性替换具体... -
2 votesanswersviews
开放封闭原则与构造函数
学习'SOLID'原理我想知道如果我需要为类添加更多扩展，可以修改构造函数，例如 . 商业逻辑 . 从我所学到的，它看起来像修改构造函数我违反了'open-closed'原则，但是如果我需要注入另一个类来执行某些逻辑呢？如果没有构造函数修改，我怎么能这样做，一般来说，构造函数修改是否违反了'open-closed'原则？ 我们来看一个例子吧 . 有一个界面 public interface Sho... -
4 votesanswersviews
我是否违反了“开放/封闭”原则？
场景：我在类字段中存储了一些信息（例如，双精度数组）（比如字段 Measurements ，类 MeasureData 中的整数数组） . 现在我想使用这些数据来执行一些计算（例如计算数组的算术平均值，最大值和最小值） . 目前，我不需要对这些数据进行任何其他操作（例如，我可能需要获得标准偏差，总和或其他） . 我将有许多 MeasureData 类型的对象 . 解决方案：我可以编写一个类 Cal... -
723 votesanswersviews
Liskov替代原则的例子是什么？
我听说Liskov替换原则（LSP）是面向对象设计的基本原则 . 它是什么以及它的使用例子是什么？ -
2 votesanswersviews
这会违反开放/封闭原则吗？
我下午大部分时间都在阅读开放/封闭原则，我似乎无法理解它 . 以下是我已经读过的一些推荐文章，似乎我错过了一些东西 . Understanding the Open Closed Principle The end of dependency injection - who creates the dependencies? 假设我有一个基础通用存储库，它公开了一些最通用的方法，可以满... -
1 votesanswersviews
关于新功能的开放式原则
关于开闭原则我有些不明白 . 假设您已完成此代码： public abstract class Player { public string Name { get; set; } public int Level { get; set; } } public sealed class Fighter : Player { /* ... */ } public sealed cla... -
0 votesanswersviews
微服务共享域层
我对微服务架构有疑问 . 我们正在开发ERP，并且有一些微服务，例如人力资源，身份，订单等 . 我们为所有这些层共有的实体实现了共享域层，包括Company，Location和一些值对象的抽象（接口） . 我的问题是：微服务共享项的边界是什么，有多糟糕？ 在这种情况下，每个微服务的那些共享实体都是相同的，这样可以帮助我们编写更少的代码，同时创建一个小的耦合级别 .