关于OOP思想和该如何设计一个类

想的太多了。再好的东西，也不能滥用。简单的一个字典功能，实在没必要大动干戈。

我的系统中也有过字典功能。通过编码查名称，或者其它相关信息。首先这些信息放置在一个文件中，不管是二进制还是文本。然后对应有一个字典类。用类是因为对于字典文件需要提供多种查询函数，而不只是一个。
当然，这是在字典文件比较少的时候的处理。如果比较多的话，倒是需要进行优化考虑。
不过对于设计模式也好，各种原则也好，我觉得要看情况使用。并非模式的就好，原则的就好。对我来说，主要看后续的扩展的变化的可控度来选择合理的方式。

如果是我的话我会选择前者，每个函数对应一个功能，函数之间相对独立没什么耦合，后期增加功能也就增加个函数，不会有什么太大影响。套了设计模式加了一堆类，每个类就那么1，2个函数，感觉有点复杂，刻意套用模式的痕迹。菜鸟之言有什么错误的请各位指正

莫非LZ和我一个公司的？
LZ可以这样

class CDataDictionary    //该类管理字典数据

{

}



class Command           //该类作为基类管理行为

{

   Command(CDataDictionary& data);

   int Translate(char* sz)=0;

}



class ColorCommad:public command

{

}

这样你扩展字典数据以及查询行为时都很方便

Quote: 引用 7 楼 My_ID_is_NULL 的回复:

莫非LZ和我一个公司的？
LZ可以这样

class CDataDictionary    //该类管理字典数据

{

}



class Command           //该类作为基类管理行为

{

   Command(CDataDictionary& data);

   int Translate(char* sz)=0;

}



class ColorCommad:public command

{

}

这样你扩展字典数据以及查询行为时都很方便

都是安防的吧，你哪家？

Quote: 引用 9 楼 xiaoxiaoyu85 的回复:

Quote: 引用 7 楼 My_ID_is_NULL 的回复:

莫非LZ和我一个公司的？
LZ可以这样

class CDataDictionary    //该类管理字典数据

{

}



class Command           //该类作为基类管理行为

{

   Command(CDataDictionary& data);

   int Translate(char* sz)=0;

}



class ColorCommad:public command

{

}

这样你扩展字典数据以及查询行为时都很方便

都是安防的吧，你哪家？

海康

类内置一个私有的成员变量map，构造函数时进行初始化，通过set/get接口访问。或者使用表驱动。仅供参考。

对于LZ的问题，map已经足够，不需要硬套设计模式。否则就本末倒置了。
很多比较有用的设计模式关注的是模块之间的解耦，比如Observer。至于动态的行为替换，见仁见智，策略模式不一定就完美，表驱动法也不一定坏。
直接上代码吧，LZ可以参考：

struct ColorMap
{
public:
    static int Get(const std::string& key)
    {
        static ColorMap color_map;
        auto it = color_map.map_.find(key);
        if (color_map.map_.end() == it)
        {
            return UNKNOWN;
        }
        return it->second;
    }
private:
    ColorMap()
    {
        map_["未识别"] = UNKNOWN;
        map_["黑"] = BLACK;
        map_["蓝"] = BLUE;
        ...
    }
private:
    std::map map_;
}

使用起来就是简单的一句: int color = ColorMap::Get("蓝");
使用表驱动法，当映射项目有变化的时候，只需要修改map_初始化的地方即可，也就是一行代码的事情，其他地方不需要动。
使用策略模式，呵呵，首先你需要修改子类（子策略），可能是增加，可能是减少，也可能是变动；然后你还要修改从key到value之间的映射代码（怎么映射，看你怎么实现了，手法很多），这样你相当于做了很多本来可以省去的工作。
实际上这个问题的焦点本来就应该只是“映射关系”，也就是map_初始化的那段代码而已。使用表驱动法可以直入问题要害，一针见血。扩展性也不输策略模式。

这里我并不是反对设计模式，而是要提醒在使用模式的时候，一定要注意使用场景。LZ如果细心的话，应该已经注意到我举的例子里头实际上已经包含了一个很有名的模式 ^_^

Quote: 引用 20 楼 yao050421103 的回复:

对于LZ的问题，map已经足够，不需要硬套设计模式。否则就本末倒置了。
很多比较有用的设计模式关注的是模块之间的解耦，比如Observer。至于动态的行为替换，见仁见智，策略模式不一定就完美，表驱动法也不一定坏。
直接上代码吧，LZ可以参考：

struct ColorMap
{
public:
    static int Get(const std::string& key)
    {
        static ColorMap color_map;
        auto it = color_map.map_.find(key);
        if (color_map.map_.end() == it)
        {
            return UNKNOWN;
        }
        return it->second;
    }
private:
    ColorMap()
    {
        map_["未识别"] = UNKNOWN;
        map_["黑"] = BLACK;
        map_["蓝"] = BLUE;
        ...
    }
private:
    std::map map_;
}

使用起来就是简单的一句: int color = ColorMap::Get("蓝");
使用表驱动法，当映射项目有变化的时候，只需要修改map_初始化的地方即可，也就是一行代码的事情，其他地方不需要动。
使用策略模式，呵呵，首先你需要修改子类（子策略），可能是增加，可能是减少，也可能是变动；然后你还要修改从key到value之间的映射代码（怎么映射，看你怎么实现了，手法很多），这样你相当于做了很多本来可以省去的工作。
实际上这个问题的焦点本来就应该只是“映射关系”，也就是map_初始化的那段代码而已。使用表驱动法可以直入问题要害，一针见血。扩展性也不输策略模式。

这里我并不是反对设计模式，而是要提醒在使用模式的时候，一定要注意使用场景。LZ如果细心的话，应该已经注意到我举的例子里头实际上已经包含了一个很有名的模式 ^_^

嗯，多谢了，后来我也将类改了，使用了数组来替代map，同时也传入一个转换的初始值.这样不管字典添加多少，都不用修改类，只要在创建对象的时候使用不同的字典数组初始化对象就可以。。
这样就少写了很多代码，有时候在扩展性和简化代码之间，很难取舍，耦合的概念也是一塌糊涂。。高手推荐本书看看吧，呵呵，谢谢了，稍后晚些结题给分。

简化代码不一定会降低扩展性，两者不是非黑即白的关系。实际上很多具备扩展性的设计都是很简洁的代码，举个例子，《Modern C++ Design》里头有个著名的Typelist，只有简简单单的5行代码，但却是我目前为止见过的最精巧的5行代码，没有之一。通过它，可以非常省力且优雅地设计出函数对象（Functor，很多设计模式都使用了这个东西，比如Command，参见loki库源码）。

一般学习设计模式都有三个阶段：
1. 只有概念，没有实际经验（一般只有程序上规模了，才需要考虑结构的优化，才需要考虑引入设计模式，对几百行的代码用各种模式其实是很eggache的行为。。。）
2. 入门了，尝试在各种项目中使用（比如重构以往的代码），但往往不得要领，误用模式，把原本简单的设计复杂化（我就经历过这个阶段，现在看看当时写的代码，哎，只能对那个时候的自己说：呵呵。。。）
3. 渐渐领悟到要领，不再误用模式， 不再陷入那种叠床架屋的设计陷阱。

学习设计模式最重要的，其实是清楚地知道， 什么时候不要用模式，而不是什么时候用模式。因为很多模式是通过增加间接层来实现解耦或者扩展的目的，这样做有好有坏。坏处是增加设计的复杂度，有时候往往划不来。

设计模式针对的是程序结构的优化，只有你的程序上了规模了，必须进行结构优化了，才需要考虑引入模式。否则往往是过度设计。当然，如果仅仅是学习之用，就不必这么拘谨，随便用；但在正式项目中使用，一定要看清场合。

耦合的概念，比较典型的例子就是模型和视图的解耦，这个可以参考《Head First设计模式》里头那个著名的MVC模式的例子。

LZ可以看看《重构》那本书。设计模式通过重构代码来学习是最容易入门的。但要想弄清楚模式里头的坑，那需要大量的项目经验，大量的编码经验，不是仅仅靠看书能学会的。一句话：程序是一行一行写出来的，熟能生巧。

PS: 如果LZ使用的语言是C++，那么可以尝试使用模板来进行设计（泛型编程）。模板的威力是巨大的，不亚于GOF设计模式。推荐《Modern C++ Design》，里头有很多你闻所未闻的设计。记得我第一次看完这本书之后，只有一个感觉：我原来对模板一无所知。。。

Quote: 引用 21 楼 xiaoxiaoyu85 的回复:

Quote: 引用 20 楼 yao050421103 的回复:

对于LZ的问题，map已经足够，不需要硬套设计模式。否则就本末倒置了。
很多比较有用的设计模式关注的是模块之间的解耦，比如Observer。至于动态的行为替换，见仁见智，策略模式不一定就完美，表驱动法也不一定坏。
直接上代码吧，LZ可以参考：

struct ColorMap
{
public:
    static int Get(const std::string& key)
    {
        static ColorMap color_map;
        auto it = color_map.map_.find(key);
        if (color_map.map_.end() == it)
        {
            return UNKNOWN;
        }
        return it->second;
    }
private:
    ColorMap()
    {
        map_["未识别"] = UNKNOWN;
        map_["黑"] = BLACK;
        map_["蓝"] = BLUE;
        ...
    }
private:
    std::map map_;
}

使用起来就是简单的一句: int color = ColorMap::Get("蓝");
使用表驱动法，当映射项目有变化的时候，只需要修改map_初始化的地方即可，也就是一行代码的事情，其他地方不需要动。
使用策略模式，呵呵，首先你需要修改子类（子策略），可能是增加，可能是减少，也可能是变动；然后你还要修改从key到value之间的映射代码（怎么映射，看你怎么实现了，手法很多），这样你相当于做了很多本来可以省去的工作。
实际上这个问题的焦点本来就应该只是“映射关系”，也就是map_初始化的那段代码而已。使用表驱动法可以直入问题要害，一针见血。扩展性也不输策略模式。

这里我并不是反对设计模式，而是要提醒在使用模式的时候，一定要注意使用场景。LZ如果细心的话，应该已经注意到我举的例子里头实际上已经包含了一个很有名的模式 ^_^

嗯，多谢了，后来我也将类改了，使用了数组来替代map，同时也传入一个转换的初始值.这样不管字典添加多少，都不用修改类，只要在创建对象的时候使用不同的字典数组初始化对象就可以。。
这样就少写了很多代码，有时候在扩展性和简化代码之间，很难取舍，耦合的概念也是一塌糊涂。。高手推荐本书看看吧，呵呵，谢谢了，稍后晚些结题给分。