r*e
2 楼
上礼拜跟国内一侄子聊天，说他们班一个同学今年申请到美国上大学，基本上所有材料
都是假的，成绩单推荐信什么的，连毕业证都是假的，就这最后还真被一个差不多的学
校给录取了。突然很好奇，猥琐地问问万能的买卖提，如果想举报这孩子作假，跟谁说
呀？哈哈
都是假的，成绩单推荐信什么的，连毕业证都是假的，就这最后还真被一个差不多的学
校给录取了。突然很好奇，猥琐地问问万能的买卖提，如果想举报这孩子作假，跟谁说
呀？哈哈
v*a
3 楼
我居然看了6集了。有看完的兄弟没有？还有什么类似黎明之前，潜伏的可以看看？
T*7
4 楼
1.大气。就做事情一定要大气。唧唧索索的不要，那种只会嘘寒问暖的招数也就是俩人
单独的时候有用，男人就应该有个男人的样子。要不就白有这一层皮了吗？而且大气也
不光是说有男子气概，更是应该有气魄，会保护女人。其实实话说现在的国内的女的都
喜欢小鲜肉。等到小鲜肉这段过去了就还会发现那种大气的有男子气概的男的才是对的
。那些长的好看的小花瓶没用。
2.修边幅注意细节。修边幅不是说非要你做到特别干净，干净整洁到你有洁癖的那种。
修边幅和注意细节还有得体是一起的。首先这个男人要看着舒服，其次待人接物要得体
注意细节，最后是要日常修边幅注意自己的外貌和内在的形象。这个开始挺难我知道，
但是后面会越来越好的。很多人都能做到。真的没必要说刻意去学。其实好好的多注意
自己的细节的话还有注意改善你的工作关系啊其他的人际关系啊。所以这点做就是了，
没问题。
3.有未来有志向。没未来没想法没志向，想了一件事就去做的那种不会要的。但是要是
有完整的人生规划的男性会得到女性的更多青睐。主要是这样的男人比较有长远的目标
有发展的眼光。自然给女人安全感也大多都是成功人士或者预备役的成功人士。
单独的时候有用，男人就应该有个男人的样子。要不就白有这一层皮了吗？而且大气也
不光是说有男子气概，更是应该有气魄，会保护女人。其实实话说现在的国内的女的都
喜欢小鲜肉。等到小鲜肉这段过去了就还会发现那种大气的有男子气概的男的才是对的
。那些长的好看的小花瓶没用。
2.修边幅注意细节。修边幅不是说非要你做到特别干净，干净整洁到你有洁癖的那种。
修边幅和注意细节还有得体是一起的。首先这个男人要看着舒服，其次待人接物要得体
注意细节，最后是要日常修边幅注意自己的外貌和内在的形象。这个开始挺难我知道，
但是后面会越来越好的。很多人都能做到。真的没必要说刻意去学。其实好好的多注意
自己的细节的话还有注意改善你的工作关系啊其他的人际关系啊。所以这点做就是了，
没问题。
3.有未来有志向。没未来没想法没志向，想了一件事就去做的那种不会要的。但是要是
有完整的人生规划的男性会得到女性的更多青睐。主要是这样的男人比较有长远的目标
有发展的眼光。自然给女人安全感也大多都是成功人士或者预备役的成功人士。
y*b
5 楼
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. 还是根本就不应该设计继承关系？
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. 还是根本就不应该设计继承关系？
a*g
6 楼
录取的学校。
造假这种事情，人人打击。
【在 r***e 的大作中提到】
: 上礼拜跟国内一侄子聊天，说他们班一个同学今年申请到美国上大学，基本上所有材料
: 都是假的，成绩单推荐信什么的，连毕业证都是假的，就这最后还真被一个差不多的学
: 校给录取了。突然很好奇，猥琐地问问万能的买卖提，如果想举报这孩子作假，跟谁说
: 呀？哈哈
造假这种事情，人人打击。
【在 r***e 的大作中提到】
: 上礼拜跟国内一侄子聊天，说他们班一个同学今年申请到美国上大学，基本上所有材料
: 都是假的，成绩单推荐信什么的，连毕业证都是假的，就这最后还真被一个差不多的学
: 校给录取了。突然很好奇，猥琐地问问万能的买卖提，如果想举报这孩子作假，跟谁说
: 呀？哈哈
u*l
7 楼
老大甭急，各大剧组正在赶工
T*7
8 楼
当然也不光是这几种。但是这几种其实比较集中。所以拿出来单说一下。
b*s
9 楼
你想要做什么？
r*e
10 楼
录取学校的admissions office？
【在 a*****g 的大作中提到】
: 录取的学校。
: 造假这种事情，人人打击。
【在 a*****g 的大作中提到】
: 录取的学校。
: 造假这种事情，人人打击。
m*e
11 楼
少看点儿片子，多读点书吧你。
【在 v******a 的大作中提到】
: 我居然看了6集了。有看完的兄弟没有？还有什么类似黎明之前，潜伏的可以看看？
【在 v******a 的大作中提到】
: 我居然看了6集了。有看完的兄弟没有？还有什么类似黎明之前，潜伏的可以看看？
l*a
12 楼
base是2Dobj
D1是point (x,y)
D2是circle (x,y,r) ?
如果是,getx,gety,getr不要弄到base
D2也不要getx,gety,弄个getCentre()返回一个point(D1)就行了
D1是point (x,y)
D2是circle (x,y,r) ?
如果是,getx,gety,getr不要弄到base
D2也不要getx,gety,弄个getCentre()返回一个point(D1)就行了
S*i
13 楼
大家是觉得这问题不值得回答呢还是不知道怎么回答？嘿嘿
【在 r***e 的大作中提到】
: 上礼拜跟国内一侄子聊天，说他们班一个同学今年申请到美国上大学，基本上所有材料
: 都是假的，成绩单推荐信什么的，连毕业证都是假的，就这最后还真被一个差不多的学
: 校给录取了。突然很好奇，猥琐地问问万能的买卖提，如果想举报这孩子作假，跟谁说
: 呀？哈哈
【在 r***e 的大作中提到】
: 上礼拜跟国内一侄子聊天，说他们班一个同学今年申请到美国上大学，基本上所有材料
: 都是假的，成绩单推荐信什么的，连毕业证都是假的，就这最后还真被一个差不多的学
: 校给录取了。突然很好奇，猥琐地问问万能的买卖提，如果想举报这孩子作假，跟谁说
: 呀？哈哈
v*a
14 楼
扯蛋，你以为跟你个小屁孩样还在读博士啊？老夫拿到学位后就发誓不读书了，金瓶梅
，肉蒲团这种提高文学修养的除外。
【在 m*******e 的大作中提到】
: 少看点儿片子，多读点书吧你。
，肉蒲团这种提高文学修养的除外。
【在 m*******e 的大作中提到】
: 少看点儿片子，多读点书吧你。
b*i
15 楼
不用通用的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根本就不
加入纯需函数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根本就不
H*9
16 楼
呵呵，这个问题是挺ws的哈。
L*n
17 楼
太笼统了，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根本就不
【在 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
18 楼
这样设计类就有点奇怪，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)就行了
数学上都不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
19 楼
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根本就不
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
20 楼
上面是个简化例子，实际的情况比较复杂，研究三维颗粒同边界的相互作用，
边界可能是平面、圆柱、椭圆柱、球、椭球、超椭球等等，以及它们的组合。
显然这些形体的行为有共性，可以抽象出很多公有的行为，比如侦测颗粒同
边界是否接触；颗粒与边界之间作用点、作用力分布及统计等等。这些都可以
在基类里面设计成纯虚函数，各个形体自己实现不同的算法。
另一方面，显然各个形体有描述自身的独特的数据结构，如果这些数据结构
总是隐藏起来倒也无事，但是很多时候需要取用或改变这些数据结构，比如
根据作用力移动或旋转边界。我原贴简化了一下。
想问个设计层面的问题：
如果类之间设计成继承关系，那么类的内部是不是应该消灭model_type这类
数据成员以及get_model_type()这类函数？如果不消灭，而用switch语句来
实现，那就根本违反了ood的原则，还不如不设计类继承关系？
再不就是使用向下转换,dynamic_cast,可是这种代码同swtich语句没啥本质
区别，还没有switch语句简洁。
【在 b*******s 的大作中提到】
: 你想要做什么？
边界可能是平面、圆柱、椭圆柱、球、椭球、超椭球等等，以及它们的组合。
显然这些形体的行为有共性，可以抽象出很多公有的行为，比如侦测颗粒同
边界是否接触；颗粒与边界之间作用点、作用力分布及统计等等。这些都可以
在基类里面设计成纯虚函数，各个形体自己实现不同的算法。
另一方面，显然各个形体有描述自身的独特的数据结构，如果这些数据结构
总是隐藏起来倒也无事，但是很多时候需要取用或改变这些数据结构，比如
根据作用力移动或旋转边界。我原贴简化了一下。
想问个设计层面的问题：
如果类之间设计成继承关系，那么类的内部是不是应该消灭model_type这类
数据成员以及get_model_type()这类函数？如果不消灭，而用switch语句来
实现，那就根本违反了ood的原则，还不如不设计类继承关系？
再不就是使用向下转换,dynamic_cast,可是这种代码同swtich语句没啥本质
区别，还没有switch语句简洁。
【在 b*******s 的大作中提到】
: 你想要做什么？
y*b
21 楼
实际情况复杂一些，可能还有不同的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)就行了
【在 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
22 楼
也这么想过。可是这样似乎很不ood，违背了ocp？
问个一般性的问题，ood是不是应该消灭getType()这类函数或枚举？
【在 b***i 的大作中提到】
: 不用通用的getR也行
: 加入纯需函数getType()返回一个枚举。
: 然后Base *pb = ...
: switch (pb->getType()){
: case CIRCLE: cast pointer, 使用具体的类的
问个一般性的问题，ood是不是应该消灭getType()这类函数或枚举？
【在 b***i 的大作中提到】
: 不用通用的getR也行
: 加入纯需函数getType()返回一个枚举。
: 然后Base *pb = ...
: switch (pb->getType()){
: case CIRCLE: cast pointer, 使用具体的类的
y*b
23 楼
嗯，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?
如果不含的话，基类指针有没有办法获取子类里面增加的数据成员？
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
24 楼
C++ 有强制转换吗？
【在 y**b 的大作中提到】
: 嗯，Base含有这些函数显然违背了dip/ocp这些基本原则，这个我明确。
: 如果不含的话，基类指针有没有办法获取子类里面增加的数据成员？
:
: of
L*n
25 楼
那么基类是什么? 看起来前五个都是ellipsoid或者特殊的ellipsoid，最后一个
有点general了，也许用template把维度加进来？ particle设计成另一个类吧
【在 y**b 的大作中提到】
: 上面是个简化例子，实际的情况比较复杂，研究三维颗粒同边界的相互作用，
: 边界可能是平面、圆柱、椭圆柱、球、椭球、超椭球等等，以及它们的组合。
: 显然这些形体的行为有共性，可以抽象出很多公有的行为，比如侦测颗粒同
: 边界是否接触；颗粒与边界之间作用点、作用力分布及统计等等。这些都可以
: 在基类里面设计成纯虚函数，各个形体自己实现不同的算法。
: 另一方面，显然各个形体有描述自身的独特的数据结构，如果这些数据结构
: 总是隐藏起来倒也无事，但是很多时候需要取用或改变这些数据结构，比如
: 根据作用力移动或旋转边界。我原贴简化了一下。
: 想问个设计层面的问题：
: 如果类之间设计成继承关系，那么类的内部是不是应该消灭model_type这类
有点general了，也许用template把维度加进来？ particle设计成另一个类吧
【在 y**b 的大作中提到】
: 上面是个简化例子，实际的情况比较复杂，研究三维颗粒同边界的相互作用，
: 边界可能是平面、圆柱、椭圆柱、球、椭球、超椭球等等，以及它们的组合。
: 显然这些形体的行为有共性，可以抽象出很多公有的行为，比如侦测颗粒同
: 边界是否接触；颗粒与边界之间作用点、作用力分布及统计等等。这些都可以
: 在基类里面设计成纯虚函数，各个形体自己实现不同的算法。
: 另一方面，显然各个形体有描述自身的独特的数据结构，如果这些数据结构
: 总是隐藏起来倒也无事，但是很多时候需要取用或改变这些数据结构，比如
: 根据作用力移动或旋转边界。我原贴简化了一下。
: 想问个设计层面的问题：
: 如果类之间设计成继承关系，那么类的内部是不是应该消灭model_type这类
a*w
26 楼
点和圆都是几何元素啊。
【在 L***n 的大作中提到】
: 那么基类是什么? 看起来前五个都是ellipsoid或者特殊的ellipsoid，最后一个
: 有点general了，也许用template把维度加进来？ particle设计成另一个类吧
【在 L***n 的大作中提到】
: 那么基类是什么? 看起来前五个都是ellipsoid或者特殊的ellipsoid，最后一个
: 有点general了，也许用template把维度加进来？ particle设计成另一个类吧
L*n
27 楼
这也太general了吧，设计类总是要合理的抽象，而不是搞个一统天下的抽象吧
【在 a*w 的大作中提到】
: 点和圆都是几何元素啊。
【在 a*w 的大作中提到】
: 点和圆都是几何元素啊。
y*b
28 楼
倒是有，向下转换。
【在 a*w 的大作中提到】
: 点和圆都是几何元素啊。
【在 a*w 的大作中提到】
: 点和圆都是几何元素啊。
d*p
29 楼
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
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
30 楼
为什么会需要通过基类指针得到子类里增加的数据成员? 这个本身就有问题. 子类独有
的成员应该通过子类的方法来获得/处理.
【在 y**b 的大作中提到】
: 嗯，Base含有这些函数显然违背了dip/ocp这些基本原则，这个我明确。
: 如果不含的话，基类指针有没有办法获取子类里面增加的数据成员？
:
: of
的成员应该通过子类的方法来获得/处理.
【在 y**b 的大作中提到】
: 嗯，Base含有这些函数显然违背了dip/ocp这些基本原则，这个我明确。
: 如果不含的话，基类指针有没有办法获取子类里面增加的数据成员？
:
: of
y*b
31 楼
是个思路，但现在只想考虑两种简单情况，其他复杂情况留给以后扩展。
颗粒是另一个类。
【在 L***n 的大作中提到】
: 这也太general了吧，设计类总是要合理的抽象，而不是搞个一统天下的抽象吧
颗粒是另一个类。
【在 L***n 的大作中提到】
: 这也太general了吧，设计类总是要合理的抽象，而不是搞个一统天下的抽象吧
a*w
32 楼
Object of Java
AnyRef of Scala
楼主只是用圆和点打个比方吧。
【在 L***n 的大作中提到】
: 这也太general了吧，设计类总是要合理的抽象，而不是搞个一统天下的抽象吧
AnyRef of Scala
楼主只是用圆和点打个比方吧。
【在 L***n 的大作中提到】
: 这也太general了吧，设计类总是要合理的抽象，而不是搞个一统天下的抽象吧
d*p
33 楼
I recommand Modern C++ Design which covers a similar design issue.
【在 y**b 的大作中提到】
: 嗯，Base含有这些函数显然违背了dip/ocp这些基本原则，这个我明确。
: 如果不含的话，基类指针有没有办法获取子类里面增加的数据成员？
:
: of
【在 y**b 的大作中提到】
: 嗯，Base含有这些函数显然违背了dip/ocp这些基本原则，这个我明确。
: 如果不含的话，基类指针有没有办法获取子类里面增加的数据成员？
:
: of
a*w
34 楼
这很正常吧，比如
List list = new ArrayList();
那术语叫啥来着，type polymorphism?
【在 t****t 的大作中提到】
: 为什么会需要通过基类指针得到子类里增加的数据成员? 这个本身就有问题. 子类独有
: 的成员应该通过子类的方法来获得/处理.
L*n
35 楼
如果你把boundary 假定成 ellipsoid或者union of ellipsoids，把
数据，就是三个半轴长放在基类，然后派生类定义方法的具体实现，比如
设计检查particle是否和boundary碰撞等等，在派生类上定义distribution,
etc呢?
【在 y**b 的大作中提到】
: 是个思路，但现在只想考虑两种简单情况，其他复杂情况留给以后扩展。
: 颗粒是另一个类。
数据，就是三个半轴长放在基类，然后派生类定义方法的具体实现，比如
设计检查particle是否和boundary碰撞等等，在派生类上定义distribution,
etc呢?
【在 y**b 的大作中提到】
: 是个思路，但现在只想考虑两种简单情况，其他复杂情况留给以后扩展。
: 颗粒是另一个类。
y*b
36 楼
是的，我也意识到这个问题。
可是看effective c++第二版item 39，里面有这种用法，有时候很难避免。
而里面建议的一个解决办法就是使用虚函数，这又导致基类依赖于子类。
http://blog.csdn.net/fengxinziyang/article/details/5908860
【在 t****t 的大作中提到】
: 为什么会需要通过基类指针得到子类里增加的数据成员? 这个本身就有问题. 子类独有
: 的成员应该通过子类的方法来获得/处理.
可是看effective c++第二版item 39，里面有这种用法，有时候很难避免。
而里面建议的一个解决办法就是使用虚函数，这又导致基类依赖于子类。
http://blog.csdn.net/fengxinziyang/article/details/5908860
【在 t****t 的大作中提到】
: 为什么会需要通过基类指针得到子类里增加的数据成员? 这个本身就有问题. 子类独有
: 的成员应该通过子类的方法来获得/处理.
L*n
37 楼
用虚函数设计一个interface还是合理的，比如基类是boundary，子类具体实现碰撞检
查吧，但是似乎也不能抽象的太厉害了
【在 y**b 的大作中提到】
: 是的，我也意识到这个问题。
: 可是看effective c++第二版item 39，里面有这种用法，有时候很难避免。
: 而里面建议的一个解决办法就是使用虚函数，这又导致基类依赖于子类。
: http://blog.csdn.net/fengxinziyang/article/details/5908860
查吧，但是似乎也不能抽象的太厉害了
【在 y**b 的大作中提到】
: 是的，我也意识到这个问题。
: 可是看effective c++第二版item 39，里面有这种用法，有时候很难避免。
: 而里面建议的一个解决办法就是使用虚函数，这又导致基类依赖于子类。
: http://blog.csdn.net/fengxinziyang/article/details/5908860
L*n
38 楼
又想了一下，这个问题还是挺有意思的，我猜你想从基类里得到边界
的几何特征？为什么需要这个信息？
【在 y**b 的大作中提到】
: 是的，我也意识到这个问题。
: 可是看effective c++第二版item 39，里面有这种用法，有时候很难避免。
: 而里面建议的一个解决办法就是使用虚函数，这又导致基类依赖于子类。
: http://blog.csdn.net/fengxinziyang/article/details/5908860
的几何特征？为什么需要这个信息？
【在 y**b 的大作中提到】
: 是的，我也意识到这个问题。
: 可是看effective c++第二版item 39，里面有这种用法，有时候很难避免。
: 而里面建议的一个解决办法就是使用虚函数，这又导致基类依赖于子类。
: http://blog.csdn.net/fengxinziyang/article/details/5908860
t*t
39 楼
这只是拿到了基类的指针, 但是你没有通过这个指针access ArrayList独有的方法对不
对.
【在 a*w 的大作中提到】
:
: 这很正常吧，比如
: List list = new ArrayList();
: 那术语叫啥来着，type polymorphism?
对.
【在 a*w 的大作中提到】
:
: 这很正常吧，比如
: List list = new ArrayList();
: 那术语叫啥来着，type polymorphism?
t*t
40 楼
EC++我看过, 没觉得有什么问题. 虚函数本身不导致基类依赖于子类, 我不明白你担心
什么事情. 我记得java里所有的函数都是虚的.
【在 y**b 的大作中提到】
: 是的，我也意识到这个问题。
: 可是看effective c++第二版item 39，里面有这种用法，有时候很难避免。
: 而里面建议的一个解决办法就是使用虚函数，这又导致基类依赖于子类。
: http://blog.csdn.net/fengxinziyang/article/details/5908860
什么事情. 我记得java里所有的函数都是虚的.
【在 y**b 的大作中提到】
: 是的，我也意识到这个问题。
: 可是看effective c++第二版item 39，里面有这种用法，有时候很难避免。
: 而里面建议的一个解决办法就是使用虚函数，这又导致基类依赖于子类。
: http://blog.csdn.net/fengxinziyang/article/details/5908860
y*b
41 楼
总有需要这种信息的时候。
比如由6个平面边界围成一个cuboid形状的压力加载器，每个边界都可以运动，自然需要
它的信息。
复杂一点的情况，6个边界设计成可以互相错动(实验室就有这类设备)，每个边界同颗粒
接触的实际面积是不停地变化的，每个边界的面积取决于相邻的四块边界，也需要这类
信息。
如果压力加载器是一个类的话，这个类包含6个边界，那么显然希望通过基类指针来处理
这6个边界。如果将其中某个平面边界替换成球面边界，代码也能处理。
【在 L***n 的大作中提到】
: 又想了一下，这个问题还是挺有意思的，我猜你想从基类里得到边界
: 的几何特征？为什么需要这个信息？
比如由6个平面边界围成一个cuboid形状的压力加载器，每个边界都可以运动，自然需要
它的信息。
复杂一点的情况，6个边界设计成可以互相错动(实验室就有这类设备)，每个边界同颗粒
接触的实际面积是不停地变化的，每个边界的面积取决于相邻的四块边界，也需要这类
信息。
如果压力加载器是一个类的话，这个类包含6个边界，那么显然希望通过基类指针来处理
这6个边界。如果将其中某个平面边界替换成球面边界，代码也能处理。
【在 L***n 的大作中提到】
: 又想了一下，这个问题还是挺有意思的，我猜你想从基类里得到边界
: 的几何特征？为什么需要这个信息？
t*t
42 楼
简单的来说, "运动"这个概念应该由子类本身处理. 如果有两个以上的对象
interaction, 那么你需要一个类似Mediator pattern的东西来包装interaction本身.
需要
颗粒
处理
【在 y**b 的大作中提到】
: 总有需要这种信息的时候。
: 比如由6个平面边界围成一个cuboid形状的压力加载器，每个边界都可以运动，自然需要
: 它的信息。
: 复杂一点的情况，6个边界设计成可以互相错动(实验室就有这类设备)，每个边界同颗粒
: 接触的实际面积是不停地变化的，每个边界的面积取决于相邻的四块边界，也需要这类
: 信息。
: 如果压力加载器是一个类的话，这个类包含6个边界，那么显然希望通过基类指针来处理
: 这6个边界。如果将其中某个平面边界替换成球面边界，代码也能处理。
interaction, 那么你需要一个类似Mediator pattern的东西来包装interaction本身.
需要
颗粒
处理
【在 y**b 的大作中提到】
: 总有需要这种信息的时候。
: 比如由6个平面边界围成一个cuboid形状的压力加载器，每个边界都可以运动，自然需要
: 它的信息。
: 复杂一点的情况，6个边界设计成可以互相错动(实验室就有这类设备)，每个边界同颗粒
: 接触的实际面积是不停地变化的，每个边界的面积取决于相邻的四块边界，也需要这类
: 信息。
: 如果压力加载器是一个类的话，这个类包含6个边界，那么显然希望通过基类指针来处理
: 这6个边界。如果将其中某个平面边界替换成球面边界，代码也能处理。
L*n
43 楼
o i c, boundary不是简单的ellipsoid而是一个3d(or 2d?) surface, 如果是检查
粒子接触面积的话，在子类实现方法是不是更自然一点?基类提供一个纯虚函数
行吗，基类自己计算几何的信息没必要吧
需要
颗粒
处理
【在 y**b 的大作中提到】
: 总有需要这种信息的时候。
: 比如由6个平面边界围成一个cuboid形状的压力加载器，每个边界都可以运动，自然需要
: 它的信息。
: 复杂一点的情况，6个边界设计成可以互相错动(实验室就有这类设备)，每个边界同颗粒
: 接触的实际面积是不停地变化的，每个边界的面积取决于相邻的四块边界，也需要这类
: 信息。
: 如果压力加载器是一个类的话，这个类包含6个边界，那么显然希望通过基类指针来处理
: 这6个边界。如果将其中某个平面边界替换成球面边界，代码也能处理。
粒子接触面积的话，在子类实现方法是不是更自然一点?基类提供一个纯虚函数
行吗，基类自己计算几何的信息没必要吧
需要
颗粒
处理
【在 y**b 的大作中提到】
: 总有需要这种信息的时候。
: 比如由6个平面边界围成一个cuboid形状的压力加载器，每个边界都可以运动，自然需要
: 它的信息。
: 复杂一点的情况，6个边界设计成可以互相错动(实验室就有这类设备)，每个边界同颗粒
: 接触的实际面积是不停地变化的，每个边界的面积取决于相邻的四块边界，也需要这类
: 信息。
: 如果压力加载器是一个类的话，这个类包含6个边界，那么显然希望通过基类指针来处理
: 这6个边界。如果将其中某个平面边界替换成球面边界，代码也能处理。
y*b
44 楼
如果抽象得好，虚函数自然不会导致基类依赖于子类。
我举例的在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里所有的函数都是虚的.
我举例的在Base中设计getX，getY，getR，显然是抽象得不好。
EC里面的例子也有这个问题：
如果不想用上面这种 "采用更特定的列表" 的方法，那就让creditInterest操作使用于
所有的银行帐户，但对于不用支付利息的帐户来说，它只是一个空操作。这个方法可以
这样来表示：
class BankAccount {
public:
virtual void creditInterest() {}
...
};
class SavingsAccount: public BankAccount { ... };
class CheckingAccount: public BankAccount { ... };
list
// 看啊，没有转换!
for (list
p != allAccounts.end();
++p) {
(*p)->creditInterest();
}
我觉得设计得好的话，BankAccount不应该有creditInterest()这个虚函数，可是那样一
来就没法使用下面基类指针的代码来。
【在 t****t 的大作中提到】
: EC++我看过, 没觉得有什么问题. 虚函数本身不导致基类依赖于子类, 我不明白你担心
: 什么事情. 我记得java里所有的函数都是虚的.
L*n
45 楼
这个循环有问题啊，如果不能假定每个BankAccount都能做有意义的creditinterest()
这个循环就不应该在所有BankAccount obj上做
【在 y**b 的大作中提到】
: 如果抽象得好，虚函数自然不会导致基类依赖于子类。
: 我举例的在Base中设计getX，getY，getR，显然是抽象得不好。
: EC里面的例子也有这个问题：
: 如果不想用上面这种 "采用更特定的列表" 的方法，那就让creditInterest操作使用于
: 所有的银行帐户，但对于不用支付利息的帐户来说，它只是一个空操作。这个方法可以
: 这样来表示：
: class BankAccount {
: public:
: virtual void creditInterest() {}
: ...
这个循环就不应该在所有BankAccount obj上做
【在 y**b 的大作中提到】
: 如果抽象得好，虚函数自然不会导致基类依赖于子类。
: 我举例的在Base中设计getX，getY，getR，显然是抽象得不好。
: EC里面的例子也有这个问题：
: 如果不想用上面这种 "采用更特定的列表" 的方法，那就让creditInterest操作使用于
: 所有的银行帐户，但对于不用支付利息的帐户来说，它只是一个空操作。这个方法可以
: 这样来表示：
: class BankAccount {
: public:
: virtual void creditInterest() {}
: ...
y*b
46 楼
所以我说他这种设计不够好。
但是代码省事啊，就一个基类指针，对所有子类完成动作。
【在 L***n 的大作中提到】
: 这个循环有问题啊，如果不能假定每个BankAccount都能做有意义的creditinterest()
: 这个循环就不应该在所有BankAccount obj上做
但是代码省事啊，就一个基类指针，对所有子类完成动作。
【在 L***n 的大作中提到】
: 这个循环有问题啊，如果不能假定每个BankAccount都能做有意义的creditinterest()
: 这个循环就不应该在所有BankAccount obj上做
t*t
47 楼
你看清楚了, EC里的例子是用来说明"避免'向下转换'", 举个例子不是让你学的, 是让
你避免的.
【在 y**b 的大作中提到】
: 如果抽象得好，虚函数自然不会导致基类依赖于子类。
: 我举例的在Base中设计getX，getY，getR，显然是抽象得不好。
: EC里面的例子也有这个问题：
: 如果不想用上面这种 "采用更特定的列表" 的方法，那就让creditInterest操作使用于
: 所有的银行帐户，但对于不用支付利息的帐户来说，它只是一个空操作。这个方法可以
: 这样来表示：
: class BankAccount {
: public:
: virtual void creditInterest() {}
: ...
你避免的.
【在 y**b 的大作中提到】
: 如果抽象得好，虚函数自然不会导致基类依赖于子类。
: 我举例的在Base中设计getX，getY，getR，显然是抽象得不好。
: EC里面的例子也有这个问题：
: 如果不想用上面这种 "采用更特定的列表" 的方法，那就让creditInterest操作使用于
: 所有的银行帐户，但对于不用支付利息的帐户来说，它只是一个空操作。这个方法可以
: 这样来表示：
: class BankAccount {
: public:
: virtual void creditInterest() {}
: ...
y*b
48 楼
我拷贝的这段显然是避免向下转换的一个方案
【在 t****t 的大作中提到】
: 你看清楚了, EC里的例子是用来说明"避免'向下转换'", 举个例子不是让你学的, 是让
: 你避免的.
【在 t****t 的大作中提到】
: 你看清楚了, EC里的例子是用来说明"避免'向下转换'", 举个例子不是让你学的, 是让
: 你避免的.
a9
49 楼
这只是避免转换的一个方案而已，最好不要这么做。
是让
【在 y**b 的大作中提到】
: 我拷贝的这段显然是避免向下转换的一个方案
是让
【在 y**b 的大作中提到】
: 我拷贝的这段显然是避免向下转换的一个方案
k*i
50 楼
行为共性感觉用Stretegy Pattern比较合适？
【在 y**b 的大作中提到】
: 上面是个简化例子，实际的情况比较复杂，研究三维颗粒同边界的相互作用，
: 边界可能是平面、圆柱、椭圆柱、球、椭球、超椭球等等，以及它们的组合。
: 显然这些形体的行为有共性，可以抽象出很多公有的行为，比如侦测颗粒同
: 边界是否接触；颗粒与边界之间作用点、作用力分布及统计等等。这些都可以
: 在基类里面设计成纯虚函数，各个形体自己实现不同的算法。
: 另一方面，显然各个形体有描述自身的独特的数据结构，如果这些数据结构
: 总是隐藏起来倒也无事，但是很多时候需要取用或改变这些数据结构，比如
: 根据作用力移动或旋转边界。我原贴简化了一下。
: 想问个设计层面的问题：
: 如果类之间设计成继承关系，那么类的内部是不是应该消灭model_type这类
【在 y**b 的大作中提到】
: 上面是个简化例子，实际的情况比较复杂，研究三维颗粒同边界的相互作用，
: 边界可能是平面、圆柱、椭圆柱、球、椭球、超椭球等等，以及它们的组合。
: 显然这些形体的行为有共性，可以抽象出很多公有的行为，比如侦测颗粒同
: 边界是否接触；颗粒与边界之间作用点、作用力分布及统计等等。这些都可以
: 在基类里面设计成纯虚函数，各个形体自己实现不同的算法。
: 另一方面，显然各个形体有描述自身的独特的数据结构，如果这些数据结构
: 总是隐藏起来倒也无事，但是很多时候需要取用或改变这些数据结构，比如
: 根据作用力移动或旋转边界。我原贴简化了一下。
: 想问个设计层面的问题：
: 如果类之间设计成继承关系，那么类的内部是不是应该消灭model_type这类
b*s
51 楼
我不是太懂专业领域的东西，设计水平也一般，不过还是给你个参考
做两个类，第一个是颗粒类，包含存取属性的接口
第二个类是边界类，假定边界是由一组函数控制的，而函数是由一组参数控制的，这个
类包含对应的函数指针，以及控制参数
然后这两个类的实例各自放在对应的容器里，遍历颗粒类的容器，边界是否接触，作用
点等功能用类似stl的algorithm的办法来实现，不需要放在任何一个上述的类里面，
这样类之间就解耦了，维护应该不复杂
【在 y**b 的大作中提到】
: 上面是个简化例子，实际的情况比较复杂，研究三维颗粒同边界的相互作用，
: 边界可能是平面、圆柱、椭圆柱、球、椭球、超椭球等等，以及它们的组合。
: 显然这些形体的行为有共性，可以抽象出很多公有的行为，比如侦测颗粒同
: 边界是否接触；颗粒与边界之间作用点、作用力分布及统计等等。这些都可以
: 在基类里面设计成纯虚函数，各个形体自己实现不同的算法。
: 另一方面，显然各个形体有描述自身的独特的数据结构，如果这些数据结构
: 总是隐藏起来倒也无事，但是很多时候需要取用或改变这些数据结构，比如
: 根据作用力移动或旋转边界。我原贴简化了一下。
: 想问个设计层面的问题：
: 如果类之间设计成继承关系，那么类的内部是不是应该消灭model_type这类
做两个类，第一个是颗粒类，包含存取属性的接口
第二个类是边界类，假定边界是由一组函数控制的，而函数是由一组参数控制的，这个
类包含对应的函数指针，以及控制参数
然后这两个类的实例各自放在对应的容器里，遍历颗粒类的容器，边界是否接触，作用
点等功能用类似stl的algorithm的办法来实现，不需要放在任何一个上述的类里面，
这样类之间就解耦了，维护应该不复杂
【在 y**b 的大作中提到】
: 上面是个简化例子，实际的情况比较复杂，研究三维颗粒同边界的相互作用，
: 边界可能是平面、圆柱、椭圆柱、球、椭球、超椭球等等，以及它们的组合。
: 显然这些形体的行为有共性，可以抽象出很多公有的行为，比如侦测颗粒同
: 边界是否接触；颗粒与边界之间作用点、作用力分布及统计等等。这些都可以
: 在基类里面设计成纯虚函数，各个形体自己实现不同的算法。
: 另一方面，显然各个形体有描述自身的独特的数据结构，如果这些数据结构
: 总是隐藏起来倒也无事，但是很多时候需要取用或改变这些数据结构，比如
: 根据作用力移动或旋转边界。我原贴简化了一下。
: 想问个设计层面的问题：
: 如果类之间设计成继承关系，那么类的内部是不是应该消灭model_type这类
y*b
52 楼
看了一下，multimethods，还挺复杂。
【在 d****p 的大作中提到】
: I recommand Modern C++ Design which covers a similar design issue.
【在 d****p 的大作中提到】
: I recommand Modern C++ Design which covers a similar design issue.
p*o
53 楼
你先用switch实现着看看, 等你对系统理解得差不多了再决定用啥OO的方法
来改进也不迟。
【在 y**b 的大作中提到】
: 看了一下，multimethods，还挺复杂。
来改进也不迟。
【在 y**b 的大作中提到】
: 看了一下，multimethods，还挺复杂。
y*b
54 楼
我觉得也是
【在 p***o 的大作中提到】
: 你先用switch实现着看看, 等你对系统理解得差不多了再决定用啥OO的方法
: 来改进也不迟。
【在 p***o 的大作中提到】
: 你先用switch实现着看看, 等你对系统理解得差不多了再决定用啥OO的方法
: 来改进也不迟。
y*b
55 楼
这些很久以前就实现了，现在对边界这部分重新设计，所以遇到新问题。
【在 b*******s 的大作中提到】
: 我不是太懂专业领域的东西，设计水平也一般，不过还是给你个参考
: 做两个类，第一个是颗粒类，包含存取属性的接口
: 第二个类是边界类，假定边界是由一组函数控制的，而函数是由一组参数控制的，这个
: 类包含对应的函数指针，以及控制参数
: 然后这两个类的实例各自放在对应的容器里，遍历颗粒类的容器，边界是否接触，作用
: 点等功能用类似stl的algorithm的办法来实现，不需要放在任何一个上述的类里面，
: 这样类之间就解耦了，维护应该不复杂
【在 b*******s 的大作中提到】
: 我不是太懂专业领域的东西，设计水平也一般，不过还是给你个参考
: 做两个类，第一个是颗粒类，包含存取属性的接口
: 第二个类是边界类，假定边界是由一组函数控制的，而函数是由一组参数控制的，这个
: 类包含对应的函数指针，以及控制参数
: 然后这两个类的实例各自放在对应的容器里，遍历颗粒类的容器，边界是否接触，作用
: 点等功能用类似stl的algorithm的办法来实现，不需要放在任何一个上述的类里面，
: 这样类之间就解耦了，维护应该不复杂
b*s
56 楼
但是你描述的是你准备抽象很多公共的特性放到类里面，比如检测是否粒子和边界碰撞
我觉得这不应该是粒子或者边界的特性，因为 “粒子检查自己是否和边界碰撞”或者
“边界检查自己是否和粒子碰撞”在自然语义上都是说不通的
如果你把这些特性分离成类似stl的algorithm那样只针对iterators工作的东西，
你可以把边界类做得非常简单，就是一组描述函数和相应的控制参数，不存在任何你主
贴里纠结的东西
【在 y**b 的大作中提到】
: 这些很久以前就实现了，现在对边界这部分重新设计，所以遇到新问题。
我觉得这不应该是粒子或者边界的特性，因为 “粒子检查自己是否和边界碰撞”或者
“边界检查自己是否和粒子碰撞”在自然语义上都是说不通的
如果你把这些特性分离成类似stl的algorithm那样只针对iterators工作的东西，
你可以把边界类做得非常简单，就是一组描述函数和相应的控制参数，不存在任何你主
贴里纠结的东西
【在 y**b 的大作中提到】
: 这些很久以前就实现了，现在对边界这部分重新设计，所以遇到新问题。
L*n
57 楼
边界检查是否自己和粒子碰撞，几何上是检查一个点是否属于一个曲面，类比
stl相似与set::find，我认为是很自然的statement，不知到用iterator怎么处理，
这里很明显是要检查是否点坐标满足一个（或者几个之一）方程
【在 b*******s 的大作中提到】
: 但是你描述的是你准备抽象很多公共的特性放到类里面，比如检测是否粒子和边界碰撞
: 我觉得这不应该是粒子或者边界的特性，因为 “粒子检查自己是否和边界碰撞”或者
: “边界检查自己是否和粒子碰撞”在自然语义上都是说不通的
: 如果你把这些特性分离成类似stl的algorithm那样只针对iterators工作的东西，
: 你可以把边界类做得非常简单，就是一组描述函数和相应的控制参数，不存在任何你主
: 贴里纠结的东西
stl相似与set::find，我认为是很自然的statement，不知到用iterator怎么处理，
这里很明显是要检查是否点坐标满足一个（或者几个之一）方程
【在 b*******s 的大作中提到】
: 但是你描述的是你准备抽象很多公共的特性放到类里面，比如检测是否粒子和边界碰撞
: 我觉得这不应该是粒子或者边界的特性，因为 “粒子检查自己是否和边界碰撞”或者
: “边界检查自己是否和粒子碰撞”在自然语义上都是说不通的
: 如果你把这些特性分离成类似stl的algorithm那样只针对iterators工作的东西，
: 你可以把边界类做得非常简单，就是一组描述函数和相应的控制参数，不存在任何你主
: 贴里纠结的东西
y*b
58 楼
那么，记录颗粒和某个边界的全部详细接触信息和统计信息，你说应该放哪里呢？
这是我准备新增加的部分，我觉得还是放边界里面最简单，无接触时为空，有接触
时就记录。
用颗粒和边界构成一个class Assemblage，颗粒自身的作用、颗粒同边界的作用，
全部是这个class的成员函数。该class内部完成所有hybrid mpi/openmp并行计算功能。
【在 b*******s 的大作中提到】
: 但是你描述的是你准备抽象很多公共的特性放到类里面，比如检测是否粒子和边界碰撞
: 我觉得这不应该是粒子或者边界的特性，因为 “粒子检查自己是否和边界碰撞”或者
: “边界检查自己是否和粒子碰撞”在自然语义上都是说不通的
: 如果你把这些特性分离成类似stl的algorithm那样只针对iterators工作的东西，
: 你可以把边界类做得非常简单，就是一组描述函数和相应的控制参数，不存在任何你主
: 贴里纠结的东西
这是我准备新增加的部分，我觉得还是放边界里面最简单，无接触时为空，有接触
时就记录。
用颗粒和边界构成一个class Assemblage，颗粒自身的作用、颗粒同边界的作用，
全部是这个class的成员函数。该class内部完成所有hybrid mpi/openmp并行计算功能。
【在 b*******s 的大作中提到】
: 但是你描述的是你准备抽象很多公共的特性放到类里面，比如检测是否粒子和边界碰撞
: 我觉得这不应该是粒子或者边界的特性，因为 “粒子检查自己是否和边界碰撞”或者
: “边界检查自己是否和粒子碰撞”在自然语义上都是说不通的
: 如果你把这些特性分离成类似stl的algorithm那样只针对iterators工作的东西，
: 你可以把边界类做得非常简单，就是一组描述函数和相应的控制参数，不存在任何你主
: 贴里纠结的东西
y*b
59 楼
那么哪种比较好，向下转换还是设置一个getType()函数，进行switch-on-type？
【在 a9 的大作中提到】
: 这只是避免转换的一个方案而已，最好不要这么做。
:
: 是让
【在 a9 的大作中提到】
: 这只是避免转换的一个方案而已，最好不要这么做。
:
: 是让
b*s
60 楼
这样实现当然没问题，但这个点属于这个表面么？
算法分离出来主要优点是好维护，碰撞检测你只要维护一套代码，实际上就是把点坐标
代入到一组描述表面的方程然后看看结果，每个类都维护一套差异不大的代码我觉得没
必要
iterator只是用来提供容器无关的数据访问，我想和算法没什么关系
【在 L***n 的大作中提到】
: 边界检查是否自己和粒子碰撞，几何上是检查一个点是否属于一个曲面，类比
: stl相似与set::find，我认为是很自然的statement，不知到用iterator怎么处理，
: 这里很明显是要检查是否点坐标满足一个（或者几个之一）方程
算法分离出来主要优点是好维护，碰撞检测你只要维护一套代码，实际上就是把点坐标
代入到一组描述表面的方程然后看看结果，每个类都维护一套差异不大的代码我觉得没
必要
iterator只是用来提供容器无关的数据访问，我想和算法没什么关系
【在 L***n 的大作中提到】
: 边界检查是否自己和粒子碰撞，几何上是检查一个点是否属于一个曲面，类比
: stl相似与set::find，我认为是很自然的statement，不知到用iterator怎么处理，
: 这里很明显是要检查是否点坐标满足一个（或者几个之一）方程
L*n
61 楼
取决与怎么model particle
我同意，我本来是认为对不同类型的函数,(linear, quadratic, ...)和不同的surface
union, 也许检查碰撞的impplementation需要不同，但是想想看，也许只是iterate是
否函数为0即可，这样你的设计确实更好。
【在 b*******s 的大作中提到】
: 这样实现当然没问题，但这个点属于这个表面么？
: 算法分离出来主要优点是好维护，碰撞检测你只要维护一套代码，实际上就是把点坐标
: 代入到一组描述表面的方程然后看看结果，每个类都维护一套差异不大的代码我觉得没
: 必要
: iterator只是用来提供容器无关的数据访问，我想和算法没什么关系
k*g
62 楼
真心奉劝LZ，用CGAL，不要闭门造车，reinvent the whole world in your own
geometry library，把自己搅死
http://www.cgal.org/
geometry library，把自己搅死
http://www.cgal.org/
b*s
63 楼
你要统计单个粒子和不同表面的接触信息时，你会倾向于让粒子保存碰撞信息，如果你
想统计单个表面有多少粒子来碰撞过，你会让表面来保存，应付你目前的使用都没问题
你的设计就是把某个碰撞事件和表面这个类耦合在一起，我觉得不是很合理，将来会怎
样进行统计可能你很难估计，这时不如设计一个log类，存碰撞记录
比如你实验做完了，突然发现某个时间段的数据不要了，用你的设计你就得一个一个访
问所有的表面类，在里面找出符合时间段特点的记录，然后删除，如果表面数量很巨大
，而粒子数量很少，或者碰撞很少，你的程序效率是很低的
而用log类的列表，按时间顺序存放的，你可以折半查找，碰撞次数的对数时间可以找
到，甚至提
前对时间优化过，有index，常数时间可以找到
另外我觉得类越做越大不是个好现象
能。
【在 y**b 的大作中提到】
: 那么，记录颗粒和某个边界的全部详细接触信息和统计信息，你说应该放哪里呢？
: 这是我准备新增加的部分，我觉得还是放边界里面最简单，无接触时为空，有接触
: 时就记录。
: 用颗粒和边界构成一个class Assemblage，颗粒自身的作用、颗粒同边界的作用，
: 全部是这个class的成员函数。该class内部完成所有hybrid mpi/openmp并行计算功能。
想统计单个表面有多少粒子来碰撞过，你会让表面来保存，应付你目前的使用都没问题
你的设计就是把某个碰撞事件和表面这个类耦合在一起，我觉得不是很合理，将来会怎
样进行统计可能你很难估计，这时不如设计一个log类，存碰撞记录
比如你实验做完了，突然发现某个时间段的数据不要了，用你的设计你就得一个一个访
问所有的表面类，在里面找出符合时间段特点的记录，然后删除，如果表面数量很巨大
，而粒子数量很少，或者碰撞很少，你的程序效率是很低的
而用log类的列表，按时间顺序存放的，你可以折半查找，碰撞次数的对数时间可以找
到，甚至提
前对时间优化过，有index，常数时间可以找到
另外我觉得类越做越大不是个好现象
能。
【在 y**b 的大作中提到】
: 那么，记录颗粒和某个边界的全部详细接触信息和统计信息，你说应该放哪里呢？
: 这是我准备新增加的部分，我觉得还是放边界里面最简单，无接触时为空，有接触
: 时就记录。
: 用颗粒和边界构成一个class Assemblage，颗粒自身的作用、颗粒同边界的作用，
: 全部是这个class的成员函数。该class内部完成所有hybrid mpi/openmp并行计算功能。
y*b
64 楼
原来颗粒间复杂接触信息就是用log类记录，边界接触信息简单多了，但还是用个log类
记录比较好。
【在 b*******s 的大作中提到】
: 你要统计单个粒子和不同表面的接触信息时，你会倾向于让粒子保存碰撞信息，如果你
: 想统计单个表面有多少粒子来碰撞过，你会让表面来保存，应付你目前的使用都没问题
: 你的设计就是把某个碰撞事件和表面这个类耦合在一起，我觉得不是很合理，将来会怎
: 样进行统计可能你很难估计，这时不如设计一个log类，存碰撞记录
: 比如你实验做完了，突然发现某个时间段的数据不要了，用你的设计你就得一个一个访
: 问所有的表面类，在里面找出符合时间段特点的记录，然后删除，如果表面数量很巨大
: ，而粒子数量很少，或者碰撞很少，你的程序效率是很低的
: 而用log类的列表，按时间顺序存放的，你可以折半查找，碰撞次数的对数时间可以找
: 到，甚至提
: 前对时间优化过，有index，常数时间可以找到
记录比较好。
【在 b*******s 的大作中提到】
: 你要统计单个粒子和不同表面的接触信息时，你会倾向于让粒子保存碰撞信息，如果你
: 想统计单个表面有多少粒子来碰撞过，你会让表面来保存，应付你目前的使用都没问题
: 你的设计就是把某个碰撞事件和表面这个类耦合在一起，我觉得不是很合理，将来会怎
: 样进行统计可能你很难估计，这时不如设计一个log类，存碰撞记录
: 比如你实验做完了，突然发现某个时间段的数据不要了，用你的设计你就得一个一个访
: 问所有的表面类，在里面找出符合时间段特点的记录，然后删除，如果表面数量很巨大
: ，而粒子数量很少，或者碰撞很少，你的程序效率是很低的
: 而用log类的列表，按时间顺序存放的，你可以折半查找，碰撞次数的对数时间可以找
: 到，甚至提
: 前对时间优化过，有index，常数时间可以找到
相关阅读
React 和 react native以前那专利问题没了吧？niuheliang很强大Android数据可视化用什么库好？问一个python memory error的问题为毛老中很少参加HackathonWindows powershell命令行不识别IP地址React native不错IBM buying Red Hat?[bssd]万物化生，阴阳五行半懂不懂的reviewer真麻烦Stop Installing Tensorflow Using pip for Performance Sake!现在吹的这些ML、DL并不是什么人工智能老年软工转Devops静态语言怎么存 values of different type into Dictionariesnetflix转向node.js，再弹go的扯淡性为啥我装了Ubuntu Server后还是两眼一抹黑啊？ (转载)看了三体后参数选择 Bayesian Optimization with Gaussian Process Prior張老師比楊振寧差的太遠了本站正在被疯狂攻击吧