C ++矩阵类层次结构 [英] C++ Matrix class hierarchy

问题描述

矩阵软件库应该具有一个根类(例如，MatrixBase)，而根类(例如SparseMatrix，UpperTriangluarMatrix等)来自更多的专门(或更受约束)矩阵类. )派生?如果是这样，派生类是否应该公开/保护/私有地派生?如果不是，它们是否应该由封装通用功能的实现类组成，并且在其他方​​面不相关?还有吗?

Should a matrix software library have a root class (e.g., MatrixBase) from which more specialized (or more constrained) matrix classes (e.g., SparseMatrix, UpperTriangluarMatrix, etc.) derive? If so, should the derived classes be derived publicly/protectively/privately? If not, should they be composed with a implementation class encapsulating common functionality and be otherwise unrelated? Something else?

我正在与一位软件开发人员同事(我本身不是)进行有关此话题的交谈，他提到从更通用的类派生一个更严格的类是一个常见的编程设计错误(例如，他使用了该示例关于如何从Ellipse类派生Circle类(与矩阵设计问题类似)不是一个好主意)，即使确实是SparseMatrix"IS A" MatrixBase.对于基本操作，基类和派生类提供的接口应该相同.对于特殊操作，派生类将具有附加的功能，这些功能可能无法为任意MatrixBase对象实现.例如，我们只能计算PositiveDefiniteMatrix类对象的cholesky分解；但是，对于基类和派生类，标量的乘积应该以相同的方式工作.同样，即使基础数据存储实现有所不同，operator()(int,int)对于任何类型的矩阵类也应能按预期工作.

I was having a conversation about this with a software developer colleague (I am not per se) who mentioned that it is a common programming design mistake to derive a more restricted class from a more general one (e.g., he used the example of how it was not a good idea to derive a Circle class from an Ellipse class as similar to the matrix design issue) even when it is true that a SparseMatrix "IS A" MatrixBase. The interface presented by both the base and derived classes should be the same for basic operations; for specialized operations, a derived class would have additional functionality that might not be possible to implement for an arbitrary MatrixBase object. For example, we can compute the cholesky decomposition only for a PositiveDefiniteMatrix class object; however, multiplication by a scalar should work the same way for both the base and derived classes. Also, even if the underlying data storage implementation differs the operator()(int,int) should work as expected for any type of matrix class.

我已经开始研究一些开放源代码矩阵库，而且看起来好像是一堆杂物(或者我正在看一堆杂物库).我正计划协助重构数学库，而这一直是争论的焦点，我想征求意见(除非对此问题确实有客观的正确答案) )，哪种设计哲学是最好的，以及任何合理方法的利弊是什么.

I have started looking at a few open-source matrix libraries and it appears like this is kind of a mixed bag (or maybe I'm looking at a mixed bag of libraries). I am planning on helping out with a refactoring of a math library where this has been a point of contention and I'd like to have opinions (that is unless there really is an objective right answer to this question) as to what design philosophy would be best and what are the pros and cons to any reasonable approach.

推荐答案

当您可以根据每个Ellipse接口修改一个尺寸时，会出现Ellipse的Circle子类(或Rectangle的Square子类)的问题.圆不再是圆(并且正方形不再是正方形).

The problem with the Circle subclass of an Ellipse (or a Square subclass of a Rectangle) occurs when you can modify one dimension per the Ellipse interface, so that the circle is no longer a circle (and the square no longer square).

如果仅允许不可修改的矩阵，那么您是安全的，并且可以自然方式构造类型层次结构.

If you only allow nonmodifiable matrices then you are safe, and you can structure your type hierarchy in the natural way.

这篇关于C ++矩阵类层次结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！