特定函数 vs 许多参数 vs 上下文相关 [英] Specific functions vs many Arguments vs context dependent

查看:18
本文介绍了特定函数 vs 许多参数 vs 上下文相关的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

假设我们有一个文本要写并且可以转换为大写或小写",并且可以在左侧、中间或右侧"打印.

Suppose we have a text to write and could be converted to "uppercase or lowercase", and can be printed "at left, center or right".

writeInUpperCaseAndCentered(char *str){//..}
writeInLowerCaseAndCentered(char *str){//..}
writeInUpperCaseAndLeft(char *str){//..}
and so on...

对比

write( char *str , int toUpper, int centered ){//..}

对比

writeComplex (char *str)
{    
    // analize str and perhaps some global variables and 
    // (under who knows what rules) put it center/left/right and upper/lowercase
}

也许还有其他选择..(欢迎)

问题是:

对于这个(反复出现的)三难困境,是否有任何良好做法经验/学术建议?

Is there is any good practice or experience/academic advice for this (recurrent) trilemma ?

我通常做的是将特定情况"的实现与内部(我的意思是不在标题中)通用的通用多参数函数结合起来,仅实现用例并隐藏丑陋的代码,但我不知道如果有我不知道的更好的方法.这样的事情让我明白了为什么要发明OOP.

What I usually do is to combine "specific case" implementation, with an internal (I mean not in header) general common many-argument function, implementing only used cases, and hiding the ugly code, but I don't know if there is a better way that I don't know. This kind of things make me realize of why OOP was invented.

推荐答案

我会避免您的第一个选项,因为正如您所说,您最终必须实现的功能数量(尽管可能仅作为宏)可能会失控.当您决定添加斜体支持时,计数加倍,下划线再次加倍.

I'd avoid your first option because as you say the number of function you end up having to implement (though possibly only as macros) can grow out of control. The count doubles when you decide to add italic support, and doubles again for underline.

我也可能会避免第二个选项.再次考虑当您发现有必要添加对斜体或下划线的支持时会发生什么.现在您需要向该函数添加另一个参数,找到您调用该函数并更新这些调用的所有情况.简而言之,很烦人,尽管您可以再次通过适当使用宏来简化流程.

I'd probably avoid the second option as well. Againg consider what happens when you find it necessary to add support for italics or underlines. Now you need to add another parameter to the function, find all of the cases where you called the function and updated those calls. In short, anoying, though once again you could probably simplify the process with appropriate use of macros.

剩下第三个选项.实际上,您可以使用 bitflags 获得其他替代方案的一些好处.例如

That leaves the third option. You can actually get some of the benefits of the other alternatives with this using bitflags. For example

#define WRITE_FORMAT_LEFT   1
#define WRITE_FORMAT_RIGHT  2
#define WRITE_FORMAT_CENTER 4
#define WRITE_FORMAT_BOLD   8
#define WRITE_FORMAT_ITALIC 16
....
write(char *string, unsigned int format)
{
  if (format & WRITE_FORMAT_LEFT)
  {
     // write left
  }

  ...
}

回答 Greg S.

我认为最大的改进是,如果我现在决定添加对带下划线的文本的支持,我需要两个步骤

I think that the biggest improvement is that it means that if I decide, at this point, to add support for underlined text I it takes two steps

  1. 在头部添加#define WRITE_FORMAT_UNDERLINE 32
  2. write() 中添加对下划线的支持.
  1. Add #define WRITE_FORMAT_UNDERLINE 32 to the header
  2. Add the support for underlines in write().

此时它可以在我喜欢的任何地方调用 write(..., ... | WRITE_FORMAT_UNLDERINE) .更重要的是,我不需要修改预先存在的 write 调用,如果我在其签名中添加一个参数,我将不得不这样做.

At this point it can call write(..., ... | WRITE_FORMAT_UNLDERINE) where ever I like. More to the point I don't need to modify pre-existing calls to write, which I would have to do if I added a parameter to its signature.

另一个潜在的好处是它允许您执行以下操作:

Another potential benefit is that it allows you do something like the following:

#define WRITE_ALERT_FORMAT  (WRITE_FORMAT_CENTER | \
                             WRITE_FORMAT_BOLD |   \
                             WRITE_FORMAT_ITALIC)

这篇关于特定函数 vs 许多参数 vs 上下文相关的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆