有没有什么好的方法来解决?
23 个解决方案
#1
什么意思？重载？
#2
把几个函数合起来，合并成一个函数
给每个函数一个特征变量，用switch选择进入不同的功能
呵呵，我的想法
给每个函数一个特征变量，用switch选择进入不同的功能
呵呵，我的想法
#3
把实现相同功能的部分提取到一个函数里面,这样的话，如果改相同的功能，只用动一个公用函数就行，如果改不同的功能，还是动要改的那个就行
如
如
void PublicFun()
{
...
}
void A()
{
...
PublicFun();
...
}
void B()
{
...
PublicFun();
...
}
void C()
{
...
PublicFun();
...
}
#4
这样看你的函数是怎样的。
好的想法应该是把公共的部分提取出来，独立成一个辅助函数，变化的部分由各个外延函数来提供。
还有，你用的什么语言呢？ C 还是 C++？
更大的可能是一组辅助函数，因为你说很大。用在C++上，有可能是一组类。
#5
喔～～～～
看来 anglecloudy 跟我观点一致。
我找到靠山了 ^_^
#6
重构、设计模式
#7
刚开始都好啊 基本没问题
但是一个程序出来了后, 客户老是有很多要求啊.要不断的更新啊.
如果把很多特殊的情况都写在一起,程序太难看,而且跟以前的代码改动很大, 不方便别人维护.
拿出公共的部分, 也有些不好看, 我始终认为把一个程序分的太小不利于理解.
其实主要的代码,负责计算的部分都没问题.主要是控制流程之类的.
有没有什么好的方法, 改一个地方其他地方都可以搞定, 用类开销太大了吧, 不就一个函数吗?
但是一个程序出来了后, 客户老是有很多要求啊.要不断的更新啊.
如果把很多特殊的情况都写在一起,程序太难看,而且跟以前的代码改动很大, 不方便别人维护.
拿出公共的部分, 也有些不好看, 我始终认为把一个程序分的太小不利于理解.
其实主要的代码,负责计算的部分都没问题.主要是控制流程之类的.
有没有什么好的方法, 改一个地方其他地方都可以搞定, 用类开销太大了吧, 不就一个函数吗?
#8
务实为主，不用类也挺好。关键看情况。
“我始终认为把一个程序分的太小不利于理解”这通常是心理因素和名称是否起的好。定义要单一。拆分子函数通常被认为是提高软件质量和维护性的法宝。代码大全2上的观点：子程序50~150行是比较好的。你可以用这个做个无理性的衡量。
开销靠感觉通常是不准确的。这个靠测试才能决定。不是热点部分，“以代码是给人看的，其次才是机器”这样的观点为主。
#9
代码是给机器编译，不是给人编译的。
临时的2种想法：
hook，在需要更改的地方统一hook，比如统一添加一个函数调用、一个 goto，在跳转目标编码特殊功能
wapper，原函数功能不变，包装一个调用原函数的特殊函数。
临时的2种想法：
hook，在需要更改的地方统一hook，比如统一添加一个函数调用、一个 goto，在跳转目标编码特殊功能
wapper，原函数功能不变，包装一个调用原函数的特殊函数。
#10
相同的东西，提一个共通出来，
大家调用就可以了吧。
大家调用就可以了吧。
#11
把公共的部分提取出来，单独用一个函数实现。
#12
看《重构：改善既有代码的设计》
#13
一个函数只实现一种特定的功能。
#14
使用重载
#15
多写几个版本
#16
建议你看看 design in pattern 方面的书籍。
给你几个建议：
1. OCP 就是软件代码的 开闭原则。 意思就是对扩展开放，对修改关闭。
2. 哪里有变化就封装哪里。
3. 建议你对接口编程，避免代码的紧耦合。
如果我说的有点抽象的话，可以加入我们的qq群： 26300976 一起来讨论。
不管是C 还是 C++ 也好，请注意代码的耦合度问题。
你的代码就是典型的紧耦合问题，太经典的紧耦合问题了。
总之， 抽象不要依赖于实现，实现要依赖于抽象。 如果这句话你理解了
那么就对你先有的问题有个清晰的了解了。
给你几个建议：
1. OCP 就是软件代码的 开闭原则。 意思就是对扩展开放，对修改关闭。
2. 哪里有变化就封装哪里。
3. 建议你对接口编程，避免代码的紧耦合。
如果我说的有点抽象的话，可以加入我们的qq群： 26300976 一起来讨论。
不管是C 还是 C++ 也好，请注意代码的耦合度问题。
你的代码就是典型的紧耦合问题，太经典的紧耦合问题了。
总之， 抽象不要依赖于实现，实现要依赖于抽象。 如果这句话你理解了
那么就对你先有的问题有个清晰的了解了。
#17
该回复于2009-02-25 10:24:15被版主删除
#18
该回复于2009-03-05 09:22:48被版主删除
#19
看看《重构》这本书里的解释吧。
#20
利用函数指针啊
#21
一个原则：最好是一个函数只完成一件事。
如果多个函数实现的功能差不多，重载、继承都是不错的方法。要不，就把公共操作提取出来。
如果多个函数实现的功能差不多，重载、继承都是不错的方法。要不，就把公共操作提取出来。
#22
不懂，up
#23
不懂，up
#1
什么意思？重载？
#2
把几个函数合起来，合并成一个函数
给每个函数一个特征变量，用switch选择进入不同的功能
呵呵，我的想法
给每个函数一个特征变量，用switch选择进入不同的功能
呵呵，我的想法
#3
把实现相同功能的部分提取到一个函数里面,这样的话，如果改相同的功能，只用动一个公用函数就行，如果改不同的功能，还是动要改的那个就行
如
如
void PublicFun()
{
...
}
void A()
{
...
PublicFun();
...
}
void B()
{
...
PublicFun();
...
}
void C()
{
...
PublicFun();
...
}
#4
这样看你的函数是怎样的。
好的想法应该是把公共的部分提取出来，独立成一个辅助函数，变化的部分由各个外延函数来提供。
还有，你用的什么语言呢？ C 还是 C++？
更大的可能是一组辅助函数，因为你说很大。用在C++上，有可能是一组类。
#5
喔～～～～
看来 anglecloudy 跟我观点一致。
我找到靠山了 ^_^
#6
重构、设计模式
#7
刚开始都好啊 基本没问题
但是一个程序出来了后, 客户老是有很多要求啊.要不断的更新啊.
如果把很多特殊的情况都写在一起,程序太难看,而且跟以前的代码改动很大, 不方便别人维护.
拿出公共的部分, 也有些不好看, 我始终认为把一个程序分的太小不利于理解.
其实主要的代码,负责计算的部分都没问题.主要是控制流程之类的.
有没有什么好的方法, 改一个地方其他地方都可以搞定, 用类开销太大了吧, 不就一个函数吗?
但是一个程序出来了后, 客户老是有很多要求啊.要不断的更新啊.
如果把很多特殊的情况都写在一起,程序太难看,而且跟以前的代码改动很大, 不方便别人维护.
拿出公共的部分, 也有些不好看, 我始终认为把一个程序分的太小不利于理解.
其实主要的代码,负责计算的部分都没问题.主要是控制流程之类的.
有没有什么好的方法, 改一个地方其他地方都可以搞定, 用类开销太大了吧, 不就一个函数吗?
#8
务实为主，不用类也挺好。关键看情况。
“我始终认为把一个程序分的太小不利于理解”这通常是心理因素和名称是否起的好。定义要单一。拆分子函数通常被认为是提高软件质量和维护性的法宝。代码大全2上的观点：子程序50~150行是比较好的。你可以用这个做个无理性的衡量。
开销靠感觉通常是不准确的。这个靠测试才能决定。不是热点部分，“以代码是给人看的，其次才是机器”这样的观点为主。
#9
代码是给机器编译，不是给人编译的。
临时的2种想法：
hook，在需要更改的地方统一hook，比如统一添加一个函数调用、一个 goto，在跳转目标编码特殊功能
wapper，原函数功能不变，包装一个调用原函数的特殊函数。
临时的2种想法：
hook，在需要更改的地方统一hook，比如统一添加一个函数调用、一个 goto，在跳转目标编码特殊功能
wapper，原函数功能不变，包装一个调用原函数的特殊函数。
#10
相同的东西，提一个共通出来，
大家调用就可以了吧。
大家调用就可以了吧。
#11
把公共的部分提取出来，单独用一个函数实现。
#12
看《重构：改善既有代码的设计》
#13
一个函数只实现一种特定的功能。
#14
使用重载
#15
多写几个版本
#16
建议你看看 design in pattern 方面的书籍。
给你几个建议：
1. OCP 就是软件代码的 开闭原则。 意思就是对扩展开放，对修改关闭。
2. 哪里有变化就封装哪里。
3. 建议你对接口编程，避免代码的紧耦合。
如果我说的有点抽象的话，可以加入我们的qq群： 26300976 一起来讨论。
不管是C 还是 C++ 也好，请注意代码的耦合度问题。
你的代码就是典型的紧耦合问题，太经典的紧耦合问题了。
总之， 抽象不要依赖于实现，实现要依赖于抽象。 如果这句话你理解了
那么就对你先有的问题有个清晰的了解了。
给你几个建议：
1. OCP 就是软件代码的 开闭原则。 意思就是对扩展开放，对修改关闭。
2. 哪里有变化就封装哪里。
3. 建议你对接口编程，避免代码的紧耦合。
如果我说的有点抽象的话，可以加入我们的qq群： 26300976 一起来讨论。
不管是C 还是 C++ 也好，请注意代码的耦合度问题。
你的代码就是典型的紧耦合问题，太经典的紧耦合问题了。
总之， 抽象不要依赖于实现，实现要依赖于抽象。 如果这句话你理解了
那么就对你先有的问题有个清晰的了解了。
#17
该回复于2009-02-25 10:24:15被版主删除
#18
该回复于2009-03-05 09:22:48被版主删除
#19
看看《重构》这本书里的解释吧。
#20
利用函数指针啊
#21
一个原则：最好是一个函数只完成一件事。
如果多个函数实现的功能差不多，重载、继承都是不错的方法。要不，就把公共操作提取出来。
如果多个函数实现的功能差不多，重载、继承都是不错的方法。要不，就把公共操作提取出来。
#22
不懂，up
#23
不懂，up