y**b
发帖数: 10166 | 1 class Base(该不该有纯虚函数getX, getY, getR？)
class D1和class D2公有继承于Base
D1增加成员x，y, 实现getX, getY
D2增加成员x，y，r, 实现getX, getY, getR
Base *pb = new D2;
D2 *pd2 = new D2;
1. Base如果没有getX，getY，getR等纯虚函数，pb就无法调用getX, getY, getR,
而只有pd2可以。但是这显然失去了指针的多态性？
2. Base如果有getX，getY，getR等纯虚函数，但自身并没有x,y,r成员，这在概念上
是不是一种矛盾呢？而且设置这些虚函数很显然违背了依赖倒置原则。Base根本就不
应该有这些函数？
3. 还是根本就不应该设计继承关系？ |
b*******s
发帖数: 5216 | |
l********a
发帖数: 1154 | 3 base是2Dobj
D1是point (x,y)
D2是circle (x,y,r) ?
如果是,getx,gety,getr不要弄到base
D2也不要getx,gety,弄个getCentre()返回一个point(D1)就行了 |
b***i
发帖数: 3043 | 4 不用通用的getR也行
加入纯需函数getType()返回一个枚举。
然后Base *pb = ...
switch (pb->getType()){
case CIRCLE: cast pointer, 使用具体的类的
【在 y**b 的大作中提到】
: class Base(该不该有纯虚函数getX, getY, getR？)
: class D1和class D2公有继承于Base
: D1增加成员x，y, 实现getX, getY
: D2增加成员x，y，r, 实现getX, getY, getR
: Base *pb = new D2;
: D2 *pd2 = new D2;
: 1. Base如果没有getX，getY，getR等纯虚函数，pb就无法调用getX, getY, getR,
: 而只有pd2可以。但是这显然失去了指针的多态性？
: 2. Base如果有getX，getY，getR等纯虚函数，但自身并没有x,y,r成员，这在概念上
: 是不是一种矛盾呢？而且设置这些虚函数很显然违背了依赖倒置原则。Base根本就不
|
L***n
发帖数: 6727 | 5 太笼统了，Base和D1，D2具体是什么类啊?
【在 y**b 的大作中提到】
: class Base(该不该有纯虚函数getX, getY, getR？)
: class D1和class D2公有继承于Base
: D1增加成员x，y, 实现getX, getY
: D2增加成员x，y，r, 实现getX, getY, getR
: Base *pb = new D2;
: D2 *pd2 = new D2;
: 1. Base如果没有getX，getY，getR等纯虚函数，pb就无法调用getX, getY, getR,
: 而只有pd2可以。但是这显然失去了指针的多态性？
: 2. Base如果有getX，getY，getR等纯虚函数，但自身并没有x,y,r成员，这在概念上
: 是不是一种矛盾呢？而且设置这些虚函数很显然违背了依赖倒置原则。Base根本就不
|
L***n
发帖数: 6727 | 6 这样设计类就有点奇怪，point和circle很难想象是同一类，甚至基于同一类
数学上都不make sense吧，如果把point想象成特殊的 circle，也应该有
getr的method，不过返回0而已
【在 l********a 的大作中提到】
: base是2Dobj
: D1是point (x,y)
: D2是circle (x,y,r) ?
: 如果是,getx,gety,getr不要弄到base
: D2也不要getx,gety,弄个getCentre()返回一个point(D1)就行了
|
d****p
发帖数: 685 | 7 When you define class Base, you should only focus on Base itself, not any of
its potential children classes. So just answer this question:
Does Base::GetX|GetY|GetR make sense?
【在 y**b 的大作中提到】
: class Base(该不该有纯虚函数getX, getY, getR？)
: class D1和class D2公有继承于Base
: D1增加成员x，y, 实现getX, getY
: D2增加成员x，y，r, 实现getX, getY, getR
: Base *pb = new D2;
: D2 *pd2 = new D2;
: 1. Base如果没有getX，getY，getR等纯虚函数，pb就无法调用getX, getY, getR,
: 而只有pd2可以。但是这显然失去了指针的多态性？
: 2. Base如果有getX，getY，getR等纯虚函数，但自身并没有x,y,r成员，这在概念上
: 是不是一种矛盾呢？而且设置这些虚函数很显然违背了依赖倒置原则。Base根本就不
|
y**b
发帖数: 10166 | 8 上面是个简化例子，实际的情况比较复杂，研究三维颗粒同边界的相互作用，
边界可能是平面、圆柱、椭圆柱、球、椭球、超椭球等等，以及它们的组合。
显然这些形体的行为有共性，可以抽象出很多公有的行为，比如侦测颗粒同
边界是否接触；颗粒与边界之间作用点、作用力分布及统计等等。这些都可以
在基类里面设计成纯虚函数，各个形体自己实现不同的算法。
另一方面，显然各个形体有描述自身的独特的数据结构，如果这些数据结构
总是隐藏起来倒也无事，但是很多时候需要取用或改变这些数据结构，比如
根据作用力移动或旋转边界。我原贴简化了一下。
想问个设计层面的问题：
如果类之间设计成继承关系，那么类的内部是不是应该消灭model_type这类
数据成员以及get_model_type()这类函数？如果不消灭，而用switch语句来
实现，那就根本违反了ood的原则，还不如不设计类继承关系？
再不就是使用向下转换,dynamic_cast,可是这种代码同swtich语句没啥本质
区别，还没有switch语句简洁。
【在 b*******s 的大作中提到】
: 你想要做什么？
|
y**b
发帖数: 10166 | 9 实际情况复杂一些，可能还有不同的D3, D4，D5...，有没有通用的办法？
【在 l********a 的大作中提到】
: base是2Dobj
: D1是point (x,y)
: D2是circle (x,y,r) ?
: 如果是,getx,gety,getr不要弄到base
: D2也不要getx,gety,弄个getCentre()返回一个point(D1)就行了
|
y**b
发帖数: 10166 | 10 也这么想过。可是这样似乎很不ood，违背了ocp？
问个一般性的问题，ood是不是应该消灭getType()这类函数或枚举？
【在 b***i 的大作中提到】
: 不用通用的getR也行
: 加入纯需函数getType()返回一个枚举。
: 然后Base *pb = ...
: switch (pb->getType()){
: case CIRCLE: cast pointer, 使用具体的类的
|
|
|
y**b
发帖数: 10166 | 11 嗯，Base含有这些函数显然违背了dip/ocp这些基本原则，这个我明确。
如果不含的话，基类指针有没有办法获取子类里面增加的数据成员？
of
【在 d****p 的大作中提到】
: When you define class Base, you should only focus on Base itself, not any of
: its potential children classes. So just answer this question:
: Does Base::GetX|GetY|GetR make sense?
|
a*w
发帖数: 4495 | 12
C++ 有强制转换吗？
【在 y**b 的大作中提到】
: 嗯，Base含有这些函数显然违背了dip/ocp这些基本原则，这个我明确。
: 如果不含的话，基类指针有没有办法获取子类里面增加的数据成员？
:
: of
|
L***n
发帖数: 6727 | 13 那么基类是什么? 看起来前五个都是ellipsoid或者特殊的ellipsoid，最后一个
有点general了，也许用template把维度加进来？ particle设计成另一个类吧
【在 y**b 的大作中提到】
: 上面是个简化例子，实际的情况比较复杂，研究三维颗粒同边界的相互作用，
: 边界可能是平面、圆柱、椭圆柱、球、椭球、超椭球等等，以及它们的组合。
: 显然这些形体的行为有共性，可以抽象出很多公有的行为，比如侦测颗粒同
: 边界是否接触；颗粒与边界之间作用点、作用力分布及统计等等。这些都可以
: 在基类里面设计成纯虚函数，各个形体自己实现不同的算法。
: 另一方面，显然各个形体有描述自身的独特的数据结构，如果这些数据结构
: 总是隐藏起来倒也无事，但是很多时候需要取用或改变这些数据结构，比如
: 根据作用力移动或旋转边界。我原贴简化了一下。
: 想问个设计层面的问题：
: 如果类之间设计成继承关系，那么类的内部是不是应该消灭model_type这类
|
a*w
发帖数: 4495 | 14 点和圆都是几何元素啊。
【在 L***n 的大作中提到】
: 那么基类是什么? 看起来前五个都是ellipsoid或者特殊的ellipsoid，最后一个
: 有点general了，也许用template把维度加进来？ particle设计成另一个类吧
|
L***n
发帖数: 6727 | 15 这也太general了吧，设计类总是要合理的抽象，而不是搞个一统天下的抽象吧
【在 a*w 的大作中提到】
: 点和圆都是几何元素啊。
|
y**b
发帖数: 10166 | 16 倒是有，向下转换。
【在 a*w 的大作中提到】
: 点和圆都是几何元素啊。
|
d****p
发帖数: 685 | 17 No. And you should not even think of this idea :-)
I understand you are in a situation to perform bottom-to-up design, ie,
trying to abstract commonality from separate entities (in your cases
geometric entities with different properties).
So you may think of take a more fine-grained approach, ie, defining a set of
abstract entities and each entity inherits from/composes several abstract
entities.
You are tackling a hard design issue, like deciding whether square should be
a special case of rectangle or vice versa.
【在 y**b 的大作中提到】
: 嗯，Base含有这些函数显然违背了dip/ocp这些基本原则，这个我明确。
: 如果不含的话，基类指针有没有办法获取子类里面增加的数据成员？
:
: of
|
t****t
发帖数: 6806 | 18 为什么会需要通过基类指针得到子类里增加的数据成员? 这个本身就有问题. 子类独有
的成员应该通过子类的方法来获得/处理.
【在 y**b 的大作中提到】
: 嗯，Base含有这些函数显然违背了dip/ocp这些基本原则，这个我明确。
: 如果不含的话，基类指针有没有办法获取子类里面增加的数据成员？
:
: of
|
y**b
发帖数: 10166 | 19 是个思路，但现在只想考虑两种简单情况，其他复杂情况留给以后扩展。
颗粒是另一个类。
【在 L***n 的大作中提到】
: 这也太general了吧，设计类总是要合理的抽象，而不是搞个一统天下的抽象吧
|
a*w
发帖数: 4495 | 20 Object of Java
AnyRef of Scala
楼主只是用圆和点打个比方吧。
【在 L***n 的大作中提到】
: 这也太general了吧，设计类总是要合理的抽象，而不是搞个一统天下的抽象吧
|
|
|
d****p
发帖数: 685 | 21 I recommand Modern C++ Design which covers a similar design issue.
【在 y**b 的大作中提到】
: 嗯，Base含有这些函数显然违背了dip/ocp这些基本原则，这个我明确。
: 如果不含的话，基类指针有没有办法获取子类里面增加的数据成员？
:
: of
|
a*w
发帖数: 4495 | 22
这很正常吧，比如
List list = new ArrayList();
那术语叫啥来着，type polymorphism?
【在 t****t 的大作中提到】
: 为什么会需要通过基类指针得到子类里增加的数据成员? 这个本身就有问题. 子类独有
: 的成员应该通过子类的方法来获得/处理.
|
L***n
发帖数: 6727 | 23 如果你把boundary 假定成 ellipsoid或者union of ellipsoids，把
数据，就是三个半轴长放在基类，然后派生类定义方法的具体实现，比如
设计检查particle是否和boundary碰撞等等，在派生类上定义distribution,
etc呢?
【在 y**b 的大作中提到】
: 是个思路，但现在只想考虑两种简单情况，其他复杂情况留给以后扩展。
: 颗粒是另一个类。
|
y**b
发帖数: 10166 | 24 是的，我也意识到这个问题。
可是看effective c++第二版item 39，里面有这种用法，有时候很难避免。
而里面建议的一个解决办法就是使用虚函数，这又导致基类依赖于子类。
http://blog.csdn.net/fengxinziyang/article/details/5908860
【在 t****t 的大作中提到】
: 为什么会需要通过基类指针得到子类里增加的数据成员? 这个本身就有问题. 子类独有
: 的成员应该通过子类的方法来获得/处理.
|
L***n
发帖数: 6727 | 25 用虚函数设计一个interface还是合理的，比如基类是boundary，子类具体实现碰撞检
查吧，但是似乎也不能抽象的太厉害了
【在 y**b 的大作中提到】
: 是的，我也意识到这个问题。
: 可是看effective c++第二版item 39，里面有这种用法，有时候很难避免。
: 而里面建议的一个解决办法就是使用虚函数，这又导致基类依赖于子类。
: http://blog.csdn.net/fengxinziyang/article/details/5908860
|
L***n
发帖数: 6727 | 26 又想了一下，这个问题还是挺有意思的，我猜你想从基类里得到边界
的几何特征？为什么需要这个信息？
【在 y**b 的大作中提到】
: 是的，我也意识到这个问题。
: 可是看effective c++第二版item 39，里面有这种用法，有时候很难避免。
: 而里面建议的一个解决办法就是使用虚函数，这又导致基类依赖于子类。
: http://blog.csdn.net/fengxinziyang/article/details/5908860
|
t****t
发帖数: 6806 | 27 这只是拿到了基类的指针, 但是你没有通过这个指针access ArrayList独有的方法对不
对.
【在 a*w 的大作中提到】
:
: 这很正常吧，比如
: List list = new ArrayList();
: 那术语叫啥来着，type polymorphism?
|
t****t
发帖数: 6806 | 28 EC++我看过, 没觉得有什么问题. 虚函数本身不导致基类依赖于子类, 我不明白你担心
什么事情. 我记得java里所有的函数都是虚的.
【在 y**b 的大作中提到】
: 是的，我也意识到这个问题。
: 可是看effective c++第二版item 39，里面有这种用法，有时候很难避免。
: 而里面建议的一个解决办法就是使用虚函数，这又导致基类依赖于子类。
: http://blog.csdn.net/fengxinziyang/article/details/5908860
|
y**b
发帖数: 10166 | 29 总有需要这种信息的时候。
比如由6个平面边界围成一个cuboid形状的压力加载器，每个边界都可以运动，自然需要
它的信息。
复杂一点的情况，6个边界设计成可以互相错动(实验室就有这类设备)，每个边界同颗粒
接触的实际面积是不停地变化的，每个边界的面积取决于相邻的四块边界，也需要这类
信息。
如果压力加载器是一个类的话，这个类包含6个边界，那么显然希望通过基类指针来处理
这6个边界。如果将其中某个平面边界替换成球面边界，代码也能处理。
【在 L***n 的大作中提到】
: 又想了一下，这个问题还是挺有意思的，我猜你想从基类里得到边界
: 的几何特征？为什么需要这个信息？
|
t****t
发帖数: 6806 | 30 简单的来说, "运动"这个概念应该由子类本身处理. 如果有两个以上的对象
interaction, 那么你需要一个类似Mediator pattern的东西来包装interaction本身.
需要
颗粒
处理
【在 y**b 的大作中提到】
: 总有需要这种信息的时候。
: 比如由6个平面边界围成一个cuboid形状的压力加载器，每个边界都可以运动，自然需要
: 它的信息。
: 复杂一点的情况，6个边界设计成可以互相错动(实验室就有这类设备)，每个边界同颗粒
: 接触的实际面积是不停地变化的，每个边界的面积取决于相邻的四块边界，也需要这类
: 信息。
: 如果压力加载器是一个类的话，这个类包含6个边界，那么显然希望通过基类指针来处理
: 这6个边界。如果将其中某个平面边界替换成球面边界，代码也能处理。
|
|
|
L***n
发帖数: 6727 | 31 o i c, boundary不是简单的ellipsoid而是一个3d(or 2d?) surface, 如果是检查
粒子接触面积的话，在子类实现方法是不是更自然一点?基类提供一个纯虚函数
行吗，基类自己计算几何的信息没必要吧
需要
颗粒
处理
【在 y**b 的大作中提到】
: 总有需要这种信息的时候。
: 比如由6个平面边界围成一个cuboid形状的压力加载器，每个边界都可以运动，自然需要
: 它的信息。
: 复杂一点的情况，6个边界设计成可以互相错动(实验室就有这类设备)，每个边界同颗粒
: 接触的实际面积是不停地变化的，每个边界的面积取决于相邻的四块边界，也需要这类
: 信息。
: 如果压力加载器是一个类的话，这个类包含6个边界，那么显然希望通过基类指针来处理
: 这6个边界。如果将其中某个平面边界替换成球面边界，代码也能处理。
|
y**b
发帖数: 10166 | 32 如果抽象得好，虚函数自然不会导致基类依赖于子类。
我举例的在Base中设计getX，getY，getR，显然是抽象得不好。
EC里面的例子也有这个问题：
如果不想用上面这种 "采用更特定的列表" 的方法，那就让creditInterest操作使用于
所有的银行帐户，但对于不用支付利息的帐户来说，它只是一个空操作。这个方法可以
这样来表示：
class BankAccount {
public:
virtual void creditInterest() {}
...
};
class SavingsAccount: public BankAccount { ... };
class CheckingAccount: public BankAccount { ... };
list allAccounts;
// 看啊，没有转换!
for (list::iterator p = allAccounts.begin();
p != allAccounts.end();
++p) {
(*p)->creditInterest();
}
我觉得设计得好的话，BankAccount不应该有creditInterest()这个虚函数，可是那样一
来就没法使用下面基类指针的代码来。
【在 t****t 的大作中提到】
: EC++我看过, 没觉得有什么问题. 虚函数本身不导致基类依赖于子类, 我不明白你担心
: 什么事情. 我记得java里所有的函数都是虚的.
|
L***n
发帖数: 6727 | 33 这个循环有问题啊，如果不能假定每个BankAccount都能做有意义的creditinterest()
这个循环就不应该在所有BankAccount obj上做
【在 y**b 的大作中提到】
: 如果抽象得好，虚函数自然不会导致基类依赖于子类。
: 我举例的在Base中设计getX，getY，getR，显然是抽象得不好。
: EC里面的例子也有这个问题：
: 如果不想用上面这种 "采用更特定的列表" 的方法，那就让creditInterest操作使用于
: 所有的银行帐户，但对于不用支付利息的帐户来说，它只是一个空操作。这个方法可以
: 这样来表示：
: class BankAccount {
: public:
: virtual void creditInterest() {}
: ...
|
y**b
发帖数: 10166 | 34 所以我说他这种设计不够好。
但是代码省事啊，就一个基类指针，对所有子类完成动作。
【在 L***n 的大作中提到】
: 这个循环有问题啊，如果不能假定每个BankAccount都能做有意义的creditinterest()
: 这个循环就不应该在所有BankAccount obj上做
|
t****t
发帖数: 6806 | 35 你看清楚了, EC里的例子是用来说明"避免'向下转换'", 举个例子不是让你学的, 是让
你避免的.
【在 y**b 的大作中提到】
: 如果抽象得好，虚函数自然不会导致基类依赖于子类。
: 我举例的在Base中设计getX，getY，getR，显然是抽象得不好。
: EC里面的例子也有这个问题：
: 如果不想用上面这种 "采用更特定的列表" 的方法，那就让creditInterest操作使用于
: 所有的银行帐户，但对于不用支付利息的帐户来说，它只是一个空操作。这个方法可以
: 这样来表示：
: class BankAccount {
: public:
: virtual void creditInterest() {}
: ...
|
y**b
发帖数: 10166 | 36 我拷贝的这段显然是避免向下转换的一个方案
【在 t****t 的大作中提到】
: 你看清楚了, EC里的例子是用来说明"避免'向下转换'", 举个例子不是让你学的, 是让
: 你避免的.
|
a9
发帖数: 21638 | 37 这只是避免转换的一个方案而已，最好不要这么做。
是让
【在 y**b 的大作中提到】
: 我拷贝的这段显然是避免向下转换的一个方案
|
k******i
发帖数: 5774 | 38 行为共性感觉用Stretegy Pattern比较合适？
【在 y**b 的大作中提到】
: 上面是个简化例子，实际的情况比较复杂，研究三维颗粒同边界的相互作用，
: 边界可能是平面、圆柱、椭圆柱、球、椭球、超椭球等等，以及它们的组合。
: 显然这些形体的行为有共性，可以抽象出很多公有的行为，比如侦测颗粒同
: 边界是否接触；颗粒与边界之间作用点、作用力分布及统计等等。这些都可以
: 在基类里面设计成纯虚函数，各个形体自己实现不同的算法。
: 另一方面，显然各个形体有描述自身的独特的数据结构，如果这些数据结构
: 总是隐藏起来倒也无事，但是很多时候需要取用或改变这些数据结构，比如
: 根据作用力移动或旋转边界。我原贴简化了一下。
: 想问个设计层面的问题：
: 如果类之间设计成继承关系，那么类的内部是不是应该消灭model_type这类
|
b*******s
发帖数: 5216 | 39 我不是太懂专业领域的东西，设计水平也一般，不过还是给你个参考
做两个类，第一个是颗粒类，包含存取属性的接口
第二个类是边界类，假定边界是由一组函数控制的，而函数是由一组参数控制的，这个
类包含对应的函数指针，以及控制参数
然后这两个类的实例各自放在对应的容器里，遍历颗粒类的容器，边界是否接触，作用
点等功能用类似stl的algorithm的办法来实现，不需要放在任何一个上述的类里面，
这样类之间就解耦了，维护应该不复杂
【在 y**b 的大作中提到】
: 上面是个简化例子，实际的情况比较复杂，研究三维颗粒同边界的相互作用，
: 边界可能是平面、圆柱、椭圆柱、球、椭球、超椭球等等，以及它们的组合。
: 显然这些形体的行为有共性，可以抽象出很多公有的行为，比如侦测颗粒同
: 边界是否接触；颗粒与边界之间作用点、作用力分布及统计等等。这些都可以
: 在基类里面设计成纯虚函数，各个形体自己实现不同的算法。
: 另一方面，显然各个形体有描述自身的独特的数据结构，如果这些数据结构
: 总是隐藏起来倒也无事，但是很多时候需要取用或改变这些数据结构，比如
: 根据作用力移动或旋转边界。我原贴简化了一下。
: 想问个设计层面的问题：
: 如果类之间设计成继承关系，那么类的内部是不是应该消灭model_type这类
|
y**b
发帖数: 10166 | 40 看了一下，multimethods，还挺复杂。
【在 d****p 的大作中提到】
: I recommand Modern C++ Design which covers a similar design issue.
|
|
|
p***o
发帖数: 1252 | 41 你先用switch实现着看看, 等你对系统理解得差不多了再决定用啥OO的方法
来改进也不迟。
【在 y**b 的大作中提到】
: 看了一下，multimethods，还挺复杂。
|
y**b
发帖数: 10166 | 42 我觉得也是
【在 p***o 的大作中提到】
: 你先用switch实现着看看, 等你对系统理解得差不多了再决定用啥OO的方法
: 来改进也不迟。
|
y**b
发帖数: 10166 | 43 这些很久以前就实现了，现在对边界这部分重新设计，所以遇到新问题。
【在 b*******s 的大作中提到】
: 我不是太懂专业领域的东西，设计水平也一般，不过还是给你个参考
: 做两个类，第一个是颗粒类，包含存取属性的接口
: 第二个类是边界类，假定边界是由一组函数控制的，而函数是由一组参数控制的，这个
: 类包含对应的函数指针，以及控制参数
: 然后这两个类的实例各自放在对应的容器里，遍历颗粒类的容器，边界是否接触，作用
: 点等功能用类似stl的algorithm的办法来实现，不需要放在任何一个上述的类里面，
: 这样类之间就解耦了，维护应该不复杂
|
b*******s
发帖数: 5216 | 44 但是你描述的是你准备抽象很多公共的特性放到类里面，比如检测是否粒子和边界碰撞
我觉得这不应该是粒子或者边界的特性，因为 “粒子检查自己是否和边界碰撞”或者
“边界检查自己是否和粒子碰撞”在自然语义上都是说不通的
如果你把这些特性分离成类似stl的algorithm那样只针对iterators工作的东西，
你可以把边界类做得非常简单，就是一组描述函数和相应的控制参数，不存在任何你主
贴里纠结的东西
【在 y**b 的大作中提到】
: 这些很久以前就实现了，现在对边界这部分重新设计，所以遇到新问题。
|
L***n
发帖数: 6727 | 45 边界检查是否自己和粒子碰撞，几何上是检查一个点是否属于一个曲面，类比
stl相似与set::find，我认为是很自然的statement，不知到用iterator怎么处理，
这里很明显是要检查是否点坐标满足一个（或者几个之一）方程
【在 b*******s 的大作中提到】
: 但是你描述的是你准备抽象很多公共的特性放到类里面，比如检测是否粒子和边界碰撞
: 我觉得这不应该是粒子或者边界的特性，因为 “粒子检查自己是否和边界碰撞”或者
: “边界检查自己是否和粒子碰撞”在自然语义上都是说不通的
: 如果你把这些特性分离成类似stl的algorithm那样只针对iterators工作的东西，
: 你可以把边界类做得非常简单，就是一组描述函数和相应的控制参数，不存在任何你主
: 贴里纠结的东西
|
y**b
发帖数: 10166 | 46 那么，记录颗粒和某个边界的全部详细接触信息和统计信息，你说应该放哪里呢？
这是我准备新增加的部分，我觉得还是放边界里面最简单，无接触时为空，有接触
时就记录。
用颗粒和边界构成一个class Assemblage，颗粒自身的作用、颗粒同边界的作用，
全部是这个class的成员函数。该class内部完成所有hybrid mpi/openmp并行计算功能。
【在 b*******s 的大作中提到】
: 但是你描述的是你准备抽象很多公共的特性放到类里面，比如检测是否粒子和边界碰撞
: 我觉得这不应该是粒子或者边界的特性，因为 “粒子检查自己是否和边界碰撞”或者
: “边界检查自己是否和粒子碰撞”在自然语义上都是说不通的
: 如果你把这些特性分离成类似stl的algorithm那样只针对iterators工作的东西，
: 你可以把边界类做得非常简单，就是一组描述函数和相应的控制参数，不存在任何你主
: 贴里纠结的东西
|
y**b
发帖数: 10166 | 47 那么哪种比较好，向下转换还是设置一个getType()函数，进行switch-on-type？
【在 a9 的大作中提到】
: 这只是避免转换的一个方案而已，最好不要这么做。
:
: 是让
|
b*******s
发帖数: 5216 | 48 这样实现当然没问题，但这个点属于这个表面么？
算法分离出来主要优点是好维护，碰撞检测你只要维护一套代码，实际上就是把点坐标
代入到一组描述表面的方程然后看看结果，每个类都维护一套差异不大的代码我觉得没
必要
iterator只是用来提供容器无关的数据访问，我想和算法没什么关系
【在 L***n 的大作中提到】
: 边界检查是否自己和粒子碰撞，几何上是检查一个点是否属于一个曲面，类比
: stl相似与set::find，我认为是很自然的statement，不知到用iterator怎么处理，
: 这里很明显是要检查是否点坐标满足一个（或者几个之一）方程
|
L***n
发帖数: 6727 | 49
取决与怎么model particle
我同意，我本来是认为对不同类型的函数,(linear, quadratic, ...)和不同的surface
union, 也许检查碰撞的impplementation需要不同，但是想想看，也许只是iterate是
否函数为0即可，这样你的设计确实更好。
【在 b*******s 的大作中提到】
: 这样实现当然没问题，但这个点属于这个表面么？
: 算法分离出来主要优点是好维护，碰撞检测你只要维护一套代码，实际上就是把点坐标
: 代入到一组描述表面的方程然后看看结果，每个类都维护一套差异不大的代码我觉得没
: 必要
: iterator只是用来提供容器无关的数据访问，我想和算法没什么关系
|
k**********g
发帖数: 989 | 50 真心奉劝LZ，用CGAL，不要闭门造车，reinvent the whole world in your own
geometry library，把自己搅死
http://www.cgal.org/ |
|
|
b*******s
发帖数: 5216 | 51 你要统计单个粒子和不同表面的接触信息时，你会倾向于让粒子保存碰撞信息，如果你
想统计单个表面有多少粒子来碰撞过，你会让表面来保存，应付你目前的使用都没问题
你的设计就是把某个碰撞事件和表面这个类耦合在一起，我觉得不是很合理，将来会怎
样进行统计可能你很难估计，这时不如设计一个log类，存碰撞记录
比如你实验做完了，突然发现某个时间段的数据不要了，用你的设计你就得一个一个访
问所有的表面类，在里面找出符合时间段特点的记录，然后删除，如果表面数量很巨大
，而粒子数量很少，或者碰撞很少，你的程序效率是很低的
而用log类的列表，按时间顺序存放的，你可以折半查找，碰撞次数的对数时间可以找
到，甚至提
前对时间优化过，有index，常数时间可以找到
另外我觉得类越做越大不是个好现象
能。
【在 y**b 的大作中提到】
: 那么，记录颗粒和某个边界的全部详细接触信息和统计信息，你说应该放哪里呢？
: 这是我准备新增加的部分，我觉得还是放边界里面最简单，无接触时为空，有接触
: 时就记录。
: 用颗粒和边界构成一个class Assemblage，颗粒自身的作用、颗粒同边界的作用，
: 全部是这个class的成员函数。该class内部完成所有hybrid mpi/openmp并行计算功能。
|
y**b
发帖数: 10166 | 52 原来颗粒间复杂接触信息就是用log类记录，边界接触信息简单多了，但还是用个log类
记录比较好。
【在 b*******s 的大作中提到】
: 你要统计单个粒子和不同表面的接触信息时，你会倾向于让粒子保存碰撞信息，如果你
: 想统计单个表面有多少粒子来碰撞过，你会让表面来保存，应付你目前的使用都没问题
: 你的设计就是把某个碰撞事件和表面这个类耦合在一起，我觉得不是很合理，将来会怎
: 样进行统计可能你很难估计，这时不如设计一个log类，存碰撞记录
: 比如你实验做完了，突然发现某个时间段的数据不要了，用你的设计你就得一个一个访
: 问所有的表面类，在里面找出符合时间段特点的记录，然后删除，如果表面数量很巨大
: ，而粒子数量很少，或者碰撞很少，你的程序效率是很低的
: 而用log类的列表，按时间顺序存放的，你可以折半查找，碰撞次数的对数时间可以找
: 到，甚至提
: 前对时间优化过，有index，常数时间可以找到
|
