今天在采访中我被问到一个问题:如何更改给定的类行为而不改变其实现?
我查看了行为模式并没有找到答案。
我们谈论的是模式,固体和IoC
我认为这个问题与注入函数的某些机制有关。 我不认为它与扩展方法或继承有关。
例如,有一个类:
OrdersService{
//some methods here
}
我们需要在不改变实现的情况下使用日志记录等扩展其行为。 即我们不应该这样做:
OrdersService{
private ILogger _logger
//some methods here
OrdersService(ILogger logger)
{
_logger = logger;
}
}
答案 0 :(得分:1)
也许面试官希望你建议创建另一个继承自该类的类,并用你继承的类代替原始类?
Liskov Subtitution Principle说:
可替代性是面向对象编程的一个原则。它 声明,在计算机程序中,如果S是T的子类型,那么 类型T的对象可以用类型S的对象替换(即, 类型S的对象可以替换类型为T)的对象而不改变 该程序的任何理想属性(正确性,任务 表演等。)
ETA:似乎如果班级的原作者不打算让你能够改变行为,那么你就不能轻易做到。但是如果使用依赖注入正确创建它,则可以通过更改注入的类的标识来控制其行为的各个方面。
如果OrdersService
类采用某种类型的注入对象,例如OrderRepository
,则除了原始LoggingOrderRepository
的任务外,还可以创建执行日志记录的OrderRepository
。 1}}。 (将记录与数据访问合并并不是一个好的实现想法,但它只是一个例子。)Liskov Substitution Principle
表示OrdersService
将能够处理{ {1}}正如处理原始LoggingOrderRepository
。
还有Stategy pattern,正如大卫奥斯本在答案中所说的那样。但是,这还要求该类的原始作者打算您能够在要执行的算法族中进行选择。但是,正如你所说的,它听起来最接近原始问题。
答案 1 :(得分:0)
通过使用注入策略,您可以在不改变其实现的情况下更改类的行为。
答案 2 :(得分:0)
听起来像是Strategy Pattern。
......策略模式使用组合而不是继承。在策略模式中,行为被定义为单独的接口和实现这些接口的特定类。这允许在行为和使用该行为的类之间更好地解耦。 可以在不破坏使用它的类的情况下更改行为,并且类可以通过更改所使用的特定实现而在不需要任何重大代码更改的情况下在行为之间切换。