|
Posted on 2008-09-29 18:34 Fox 阅读(4464) 评论(31) 编辑 收藏 引用 所属分类: T技术碎语
项目中使用了消息通信机制,因为消息类型非常多,相应的,处理消息的地方代码也非常多。 自然而然想到MFC中的消息映射: 创建一个缺省MFC框架程序的解决方案Test,在Test.h中看到以下内容: class Ctest_mfcApp : public CWinApp { public: Ctest_mfcApp(); // 重写 public: virtual BOOL InitInstance(); // 实现 afx_msg void OnAppAbout(); DECLARE_MESSAGE_MAP() }; 其中,最紧要的就是DECLARE_MESSAGE_MAP() 这个宏,相关内容展开如下: struct AFX_MSGMAP_ENTRY { UINT nMessage; // windows message UINT nCode; // control code or WM_NOTIFY code UINT nID; // control ID (or 0 for windows messages) UINT nLastID; // used for entries specifying a range of control id's UINT_PTR nSig; // signature type (action) or pointer to message # AFX_PMSG pfn; // routine to call (or special value) }; struct AFX_MSGMAP { const AFX_MSGMAP* (PASCAL* pfnGetBaseMap)(); const AFX_MSGMAP_ENTRY* lpEntries; }; #define DECLARE_MESSAGE_MAP() \ protected: \ static const AFX_MSGMAP* PASCAL GetThisMessageMap(); \ virtual const AFX_MSGMAP* GetMessageMap() const; \ 其中AFX_PMSG 不再解析下去,我们认为这是一个指向特定消息对应的实现函数的函数指针,这几个宏的作用可简单理解成为Test这个项目定义了一个静态的消息映射表。当消息到来时,从消息队列中弹出消息并分发到具有入口实现的上层CWnd派生窗口。用户只需要注册消息,实现消息入口函数就够了,这在MFC中一般放在.cpp文件头部。Test.cpp中头部有以下内容: BEGIN_MESSAGE_MAP(CTest, CWinApp) ON_COMMAND(ID_APP_ABOUT, &CTest::OnAppAbout) // 基于文件的标准文档命令 ON_COMMAND(ID_FILE_NEW, &CWinApp::OnFileNew) ON_COMMAND(ID_FILE_OPEN, &CWinApp::OnFileOpen) // 标准打印设置命令 ON_COMMAND(ID_FILE_PRINT_SETUP, &CWinApp::OnFilePrintSetup) END_MESSAGE_MAP() 这里是为消息枚举值与消息实现函数建立映射,其中涉及到的宏的展开如下: #define ON_COMMAND(id, memberFxn) \ { WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSigCmd_v, \ static_cast<AFX_PMSG> (memberFxn) }, #define BEGIN_MESSAGE_MAP(theClass, baseClass) \ PTM_WARNING_DISABLE \ const AFX_MSGMAP* theClass::GetMessageMap() const \ { return GetThisMessageMap(); } \ const AFX_MSGMAP* PASCAL theClass::GetThisMessageMap() \ { \ typedef theClass ThisClass; \ typedef baseClass TheBaseClass; \ static const AFX_MSGMAP_ENTRY _messageEntries[] = \ { #define END_MESSAGE_MAP() \ {0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } \ }; \ static const AFX_MSGMAP messageMap = \ { &TheBaseClass::GetThisMessageMap, &_messageEntries[0] }; \ return &messageMap; \ } \ PTM_WARNING_RESTORE 按照上述思路得到的相似代码如下: // Test.h typedef void (* funCall)(void*); // 消息执行函数类型 struct tagMsgEntry // 消息入口结构 { int nMsgType; // 消息类型 funCall MsgRun; // 消息执行函数 }; struct tagMsgMap // 消息映射表结构 { const tagMsgMap* (__stdcall* funGetBaseMsgMap)(); const tagMsgEntry* pMsgEntries; // 消息入口集 }; class CMessage { // ... protected: static const tagMsgMap* __stdcall GetThisMsgMap(); virtual const tagMsgMap* GetMsgMap() const; }; // Test.cpp const tagMsgMap* CMessage::GetMsgMap() const { return GetThisMsgMap(); } const tagMsgMap* __stdcall CMessage::GetThisMsgMap() { static const tagMsgEntry MsgEntries[] = { { MSG_SOME_ONE, SomeOneFunc }, { MSG_SOME_TWO, SomeTwoFunc }, { MSG_NULL, NULL } }; static const tagMsgMap msgMap = { &CBaseMessage::GetThisMsgMap, // 父类消息映射表 &MsgEntries[0] }; return &msgMap; } int CMessage::MsgProc(int nMsgType) { switch( nMsgType ) { case MSG_SOME_ONE: { } break; } return CBaseMessage::MsgProc(nMsgType); } 这种处理的优点在于,子类没有定义的消息实现接口,可以使用父类接口实现。不过在现在的消息处理中,我们一般不需要由基类来完成,因此可以不依赖基类接口,使用宏可以使代码看上去更加简洁。 ___________________________________________________________ 简化版本的消息映射采用以下方式,简单清晰: // Test.h #define REG_MSG_FUNC(nMsgType, MsgFunc) \ CMessge::RegisterCallFunc(nMsgType, MsgFunc); \ typedef void (* function)(void*); typedef std::map<int, function> MSG_MAP; typedef MSG_MAP::const_iterator MSG_CITR; class CMessage { // ... public: static const MSG_MAP& GetMsgMap(); static void RegisterCallFunc(int nMsgType, void(* Func)(void *)) { s_MsgMap[nMsgType] = Func; } int CMessage::Run(int nMsgType) // 消息公用执行函数 { MSG_ITR itr = s_MsgMap.find(nMsgType); if( s_MsgMap.end() != itr ) { itr->second(this); } } protected: static MSG_MAP s_MsgMap; // 消息映射表 }; // UserTest.cpp -- 用户在使用时对自己关心的消息予以注册, 入口函数予以实现即可 REG_MSG_FUNC(MSG_SOME_ONE, SomeOneFunc) void SomeOneFunc(CBaseMessage *pMsg) { return; } ___________________________________________________________ 最近忙的焦头烂额,正好写到消息,稍微整理一下,提供些许借鉴。
Feedback
# re: 消息映射机制的简单实现[未登录] 回复 更多评论
2008-09-30 12:32 by
顶一下
前几天我也刚写了一个,用在线程消息的处理中,我的消息类型做数组下标了,直接定位取处理函数,这都是无关紧要的细节。关键在ON_COMMAND宏的展现方式,我的处理线程消息,名字起做ON_MESSAGE
整体思路基本都是一样的,呵呵。
# re: 消息映射机制的简单实现 回复 更多评论
2008-10-10 08:50 by
对于成员函数这个写法应该没用了。
# re: 消息映射机制的简单实现 回复 更多评论
2008-10-10 10:23 by
# re: 消息映射机制的简单实现 回复 更多评论
2009-02-18 02:30 by
@cppexplore 【消息类型做数组下标了,直接定位取处理函数,这都是无关紧要的细节。】 这恰恰是最重要的细节 …… 这样做得不偿失……
# re: 消息映射机制的简单实现 回复 更多评论
2009-02-18 02:35 by
@cppexplore 我再说明白一点: 既然【用消息类型做数组下标,直接定位处理函数】,为什么不直接使用虚函数?
你的方案是为了消息路由而消息路由,没能理解采用消息路由的”苦衷“——如果采用更容易理解的虚函数来实现,虚表将占用比较多的资源,不得已而采用消息路由。
# re: 消息映射机制的简单实现[未登录] 回复 更多评论
2009-02-18 12:00 by
@OwnWaterloo
欢迎来我blog讨论: http://www.cppblog.com/CppExplore 这篇 http://www.cppblog.com/CppExplore/archive/2008/11/07/66216.html下。查表是本质,为什么要使用虚函数?更容易理解?MFC的消息映射展现方式很难理解吗? 虚函数更容易扩展吗? 说到虚函数占用较多资源而导致不得已采用消息路由,我不能认同,这个因素在整个系统中的开销你有没有量化过?比如 因为采用它导致并发数下降了多少多少之类?欢迎来我blog讨论。
# re: 消息映射机制的简单实现 回复 更多评论
2009-02-18 16:29 by
@cppexplore
1. 时间消耗
时间消耗自然不用说,是你的实现最得意的部分,o(1)。 同样,虚函数也是o(1)。
2. 空间消耗
假设你总共有N个消息,你仔细看看你的实现: 是不是每个(要处理消息的)类有一个长度会N的函数表, 空间大小至少是N×sizeof(void*); 每个对象有一个指向(或间接指向)该表的指针, 空间大小至少是sizeof(void*)。
虚函数的经典实现的空间消耗也是one class one vtbl, one object one vptr,和你的实现还是相同的。
这就回答了你一个问题: 【我不能认同,这个因素在整个系统中的开销你有没有量化过?比如 因为采用它导致并发数下降了多少多少之类?】 两者的时间空间效率是完全一致的,即使我没有量化过,也可以肯定,不会导致并发数下降。
# re: 消息映射机制的简单实现 回复 更多评论
2009-02-18 16:40 by
@cppexplore 【查表是本质】 这句你说到重点了,虚函数和你实现的那个还有哪些所谓的用C实现OO的,都是查表。 【为什么要使用虚函数?更容易理解?MFC的消息映射展现方式很难理解吗? 虚函数更容易扩展吗?】 你这个实现就是在『模拟』虚函数。 上面的时空分析,可以量化,我有把握你会同意我的观点——两者时空效率完全一样——这个扩展性嘛,不容易量化 …… 你可以试着把你的实现用虚函数改写一下(再次说明,时空效率完全一样)。看看是否觉得虚函数更容易理解,更容易扩展。 btw:推荐你看看这个,MFC会什么会采用消息映射而不是虚函数的理由,《C++多态技术的实现和反思》 http://dev.yesky.com/189/2385189.shtml
# re: 消息映射机制的简单实现 回复 更多评论
2009-02-18 18:03 by
@cppexplore
再看了下你的实现,好像我们讨论的着重点不一样。
1. 你的系统里,是不是首先有这样一个需求: 因为某种原因(分布式,进程间,无锁线程),消息的发送者不能直接调用消息处理函数,而是传送一个消息代码来表示需要处理的类型?
消息代码即是win32中的WM_XX或者你的系统中的 enum MsgType { MSG_TYPE_1=65, ... };
2. 消息的处理者,又需要按照约定(即消息代码的含义),将其映射到某个处理函数中。
如 win32 中 switch (message) { case WM_XXX: return OnXXX(hwnd,message,wparam,lparam); ... }
或者你的系统中的 switch(msg->type) { case MSG_TYPE_1: do_msg_type_1_(); break; case MSG_TYPE_2: do_msg_type_2_(); break; .. default: do_default_msg_(); break; }
在这一步,确实是你的实现方式时间效率比较高。 但是在win32中, 这样做不太现实 …… 1000多个消息,表格就要包含1000多项,而且大多都是DefWndProc。
并且,在这一步中,虚函数根本就提供不了任何帮助。 你的着重点在这一步?
3. 你想实现一个消息处理者B,它对大多数消息的处理方式同A一样,这时候如何尽可能的使用A的实现? (暂不说依赖于某实现是不太恰当的设计,在MFC中多如牛毛……)
我的着重点在这里,我对处理这步的观点是: 『消息类型做数组下标了,直接定位取处理函数』与『覆写虚函数』相比,时空效率是相同的,我觉得后者更容易理解和扩展。
# re: 消息映射机制的简单实现[未登录] 回复 更多评论
2009-02-18 18:21 by
@OwnWaterloo
怎么不直接去我blog回复呢 呵呵
其实 时间消耗 之类并不是我最得意的东西,这种实现的细节 我并不太关注,所以质疑你以前说的 “虚函数占用较多资源而导致不得已采用消息路由”,如何实现并不重要,关键的是容易理解,容易扩展,容易维护,容易移植,容易简单化。
win32 你是指win32 的界面设计? 业务系统里 基本不同的消息有不同的实现,我的本意其实都不在实现,而在于简单的思想,因此是查表实现 还是虚函数实现 也都无所谓,只要最后有统一的扩展方式。
# re: 消息映射机制的简单实现[未登录] 回复 更多评论
2009-02-18 18:55 by
@OwnWaterloo
呵呵,最后的问题归结为:哪种更容易理解和扩展。
超大工程当然是数组方式之上用宏展现最容易理解和扩展了,简洁直接。几十w行的代码,用虚函数,文件数量的迅速膨胀 找个东西都找不到在哪里,所有东西交织错乱在一起,最终维护程序的人都会想:要是有张表就好了,只看表就知道那个函数处理哪个消息,而宏的展现就是如此。 当然如果用宏包裹下虚函数的实现,结果就一样了。
并且数组表只是一个思路,不携带任何面向对象的语义,在这个业务系统里可用,在那个业务系统里也可用,虚函数有这么好的移植性吗?有这么简单化吗?
# re: 消息映射机制的简单实现 回复 更多评论
2009-02-19 01:57 by
@cppexplore
【容易理解,容易扩展,容易维护,容易移植,容易简单化】 嗯,这是重点。同时我也赞同你文章里最后一句话【一句话:重要的是思想,不是平台和语言。】
"你的实现就是模拟C++虚函数的经典实现",这个观点你赞同吗? 你的系统需要考虑向C(以及不支持虚函数的语言)移植吗?
如果赞同且不需要,那么继续讨论理解、扩展、维护、简单。
你的系统具体要做什么不太了解,我用win32作例子可以吗?比如,现在需要关心的消息只有2个:
enum MsgType { WM__LBUTTONDOWN /*= 0*/, WM__SIZING, // }; struct Msg { MsgType type; HWND hwnd; WPARAM wparam; LPARAM lparam; };
如果使用C++虚函数机制:
class IHandler { public: virtual ~IHandler() {}; protected: virtual void OnLButtonDown(POINTS pt,bool ctrl,bool shift,bool l,bool m,bool r) = 0 {}; virtual void OnSizing(RECT& rc,int side) = 0 {}; public: LRESULT Do(Msg* msg) { switch (msg->type) { case WM__LBUTTONDOWN: OnLButtonDown(MAKEPOINTS(msg->lparam) ,msg->wparam & MK_CONTROL ,msg->wparam & MK_SHIFT ,msg->wparam & MK_LBUTTON ,msg->wparam & MK_MBUTTON ,msg->wparam & MK_RBUTTON); return 0; case WM__SIZING: OnSizing(*reinterpret_cast<RECT*>(msg->lparam),msg->wparam); return 0; } return DefWindowProc(msg->hwnd,msg->type,msg->wparam,msg->lparam); } };
具体的消息处理类可以这样:
class Handler1 : public IHandler { void OnLButtonDown(POINTS pt,bool ctrl,bool shift,bool l,bool m,bool r) { IHandler::OnLButtonDown(pt,ctrl,shift,l,m,r); } void OnSizing(RECT& rc,int side) { IHandler::OnSizing(rc,side); } };
上面的基类的虚函数带有默认实现,但设置为纯虚函数。
具体类必须实现每个消息处理过程,如果不关心,可以简单使用基类实现。
另一种方式:基类提供默认实现,并且不是纯虚函数;具体类只需覆写关心的消息。
另一方面,上面的基类没有使用表格,如果觉得switch case 不好维护,也可以使用表格。
两方面都采用另一种方案的话,基类就如下:
class IHandler { public: virtual ~IHandler() {}; private: virtual void OnLButtonDown(POINTS pt,bool ctrl,bool shift,bool l,bool m,bool r) {}; virtual void OnSizing(RECT& rc,int side) {}; public: LRESULT Do(Msg* msg) { assert(msg->type>=0 && msg->type<WM__SIZING); return MsgProcs[msg->type](msg->hwnd,msg->type,msg->wparam,msg->lparam,this); }
private: typedef LRESULT (*MsgProc)(HWND,MsgType,WPARAM,LPARAM,IHandler* handler); const static MsgProc MsgProcs[]; static LRESULT OnLButtonDown(HWND,MsgType,WPARAM wparam,LPARAM lparam,IHandler* handler) { handler->OnLButtonDown(MAKEPOINTS(lparam) ,wparam & MK_CONTROL ,wparam & MK_SHIFT ,wparam & MK_LBUTTON ,wparam & MK_MBUTTON ,wparam & MK_RBUTTON); return 0; } static LRESULT OnSizing(HWND,MsgType,WPARAM wparam,LPARAM lparam,IHandler* handler) { handler->OnSizing(*reinterpret_cast<RECT*>(lparam),wparam); return 0; } };
const IHandler::MsgProc IHandler::MsgProcs[] = { IHandler::OnLButtonDown, IHandler::OnSizing, };
具体类的编写就更简单: 假设仅关心OnLButtonDown
class Handler1 : public IHandler { void OnLButtonDown(POINTS pt,bool ctrl,bool shift,bool l,bool m,bool r) { printf("(%d,%d) ctrl=%d,shitf=%d\n",pt.x,pt.y,ctrl,shift); } };
# re: 消息映射机制的简单实现 回复 更多评论
2009-02-19 02:16 by
考虑扩展
添加一个新的消息处理类。
如果基类不是纯虚函数,那最简单了,覆写需要关心的消息就可以了。
如果是纯虚函数,需要实现所有消息处理函数,对不关心的消息,使用基类默认处理。
如果不是这样,请务必告诉我你是怎么不使用虚函数实现的。
添加一个新的消息种类(消息代码)
如果可以保证消息代码连续,可以使用上面的方案2,在表格中多加入一条。
如果不能保证消息代码连续(并且非常稀疏),就只能采用swtich case。
已经编写好的具体的消息处理类,如果都可以安全忽略该消息,那么可以采用上面的方案2——基类有默认实现且不纯虚——那么除了基类,已经编写好的具体类都不需要修改。
如果不全都可以安全忽略该消息,那么可以采用上面的方案1——基类有空实现,但是纯虚——具类中可以忽略该消息的,使用基类实现,不能忽略的,编写处理函数。
而你的方案,一旦添加一个新的消息处理代码(同时要保证连续),所有的消息处理类都必须在其表格中增加一项。
# re: 消息映射机制的简单实现 回复 更多评论
2009-02-19 02:16 by
移植性确实会在不支持虚函数的语言中完败。 论理解、扩展、维护、简单的话,你现在仍然觉得虚函数比不上表格吗?
# re: 消息映射机制的简单实现[未登录] 回复 更多评论
2009-02-19 10:16 by
@OwnWaterloo
呵呵 你觉得你的想法来源于面向对象的纸上谈兵(没有贬义)以及基于win32的mfc框架程序设计。
我的实现不是为了模拟虚函数的实现,只是为了实现一个易维护的消息映射而已。
首先 对象A不能直接向对象B直接发送消息,需要调用对象B的ON_send_msg,由B自己的方法向自己发送消息,由B的DO_Msg方法处理消息,当然发送动作和处理动作在不同的线程内。任何对象向B发送消息都要调用B自己的方法。也就是说对象B的具体消息类型对其它对象是不可见的。
因此对象B中的消息类型是连续的,并且不存在自己不感兴趣的消息,既然不感兴趣,就不会存在这个消息类型,只要是存在的就是感兴趣的,就是要处理的。也不存在对多个消息,处理方式相同的问题,既然处理方式相同,它们就是同一个消息。
其次 你还是回避了大型程序开发中,使用虚函数方式,文件个数膨胀的问题。
最后 我讨论的是线程间的消息传递和映射,你的有偏向于 已经发送到UI线程的消息,对责任链模式上的 各个对象的后续处理。
# re: 消息映射机制的简单实现 回复 更多评论
2009-02-19 22:42 by
@cppexplore
第1个疑问: 系统中所有类使用的消息代码是否是同一套?都是 enum MsgType { MSG_TYPE_1=65,//64一下预留,用于统一的管理控制 MSG_TYPE_2, .. MSG_TYPE_MAX }; ???
第2个疑问:(同时也是回答) 确实如你所说,我是【纸上谈兵】。 我没有【大型程序】的开发经验,更是不能理解: 【大型程序开发中,使用虚函数方式,文件个数膨胀的问题。】 这是为什么? 请指教~~~ 昨天就想问你了,字打多了就忘了……
# re: 消息映射机制的简单实现[未登录] 回复 更多评论
2009-02-19 22:51 by
@OwnWaterloo
不是同一套,只有64以下的是相同。64以上的各个线程之间可以重复,因为对其他对象是不可见得,所以不存在冲突问题。可以定义USER_MSG_START=64.
项目越大,越需要表格,容易维护,容易扩展,容易找对应关系,也就是看一个文件就知道所有,而不是在几十个上百个文件里查找。当然要看你的虚函数实现成什么样子了。
我举的例子,对象B是管理类,同时也是线程类。里面管理了很多的对象,B拿到消息也是找到对应的对象去处理,貌似你一直谈的是后续。
而你在MFC里看到的是同一套,那是因为它们都在UI线程里,同属于一个线程,一个管理类。
# re: 消息映射机制的简单实现 回复 更多评论
2009-02-19 23:23 by
@cppexplore 我觉得加QQ聊会快一点…… “六久久思武柳留灵” 不是同一套,那么A向B发一个65以上的消息,B如何知道代表什么含义呢? 要么:A只向B发64以下的消息。 要么:存在T1,T2, ... Tn个线程,每个线程下分别有 A11,A12, ... An1... A21,A22, ... An2... ... A[i][j]只会和A[i][k]直接交互 A[i][j]和A[k][l]通过某种机制间接交互 ----------------------------- 【貌似你一直谈的是后续。 】 可能是这样的,我在 http://www.cppblog.com/Fox/archive/2008/09/29/63056.aspx#74178也说了。
# re: 消息映射机制的简单实现[未登录] 回复 更多评论
2009-02-20 10:19 by
@OwnWaterloo
上班不能qq 呵呵 下班加你
A不能以指定消息值的方式向B发消息,通过调用B自身的ON_MSG方法发送。也就是除了B自己,谁也不知道它具体消息的枚举值。
64一下的也是调用B自身的方法发送,不过这些是B基类中的方法。
# re: 消息映射机制的简单实现 回复 更多评论
2011-10-15 16:04 by
人 需要一种简单的 东西来支撑属于自身内心的简单,这样的简单一直以来是无形的,就如同所有存在的 对于支撑简单的东西已经 进行过的时候,那么内心当中还是缺少对于无法割舍的简单的 内涵
# re: 消息映射机制的简单实现 回复 更多评论
2011-10-15 16:06 by
在某一种环境下面其实简单的来说在于一旦没有了这样的一种现实,简单的环境是否在可能变化的环境当中产生简单的过程那样如此简单明了
# re: 消息映射机制的简单实现 回复 更多评论
2011-10-15 16:07 by
所以自己的内心真诚的东西不是对于某一种势力的那种附和,而是对于在这个过程当中自身能够决定进入某一种势力需要的那种条件的 认可
# re: 消息映射机制的简单实现 回复 更多评论
2011-10-15 16:08 by
在各种各样的 范围内决定一个人能够简单的进行自身的活动范围内 并且 能够达到一些尽可能需要的行为内,需要的不仅仅是可靠性的 过程,更重要的是价值活动的产生
# re: 消息映射机制的简单实现 回复 更多评论
2011-10-15 16:09 by
在过程行为当中能够明确的 在于是已经形成出来的新的一种竞争力自身需要的一种内心活动 当中产生的角色转换的 过程当中需要的互动意识与能力
# re: 消息映射机制的简单实现 回复 更多评论
2011-10-15 16:10 by
因此各种各样的简单绝对不是取决于自身在竭尽全力自后需要的条件,而是自身竭尽全力的过程当中自己需要的休息的素质与能力的那种背景考量的能力
# re: 消息映射机制的简单实现 回复 更多评论
2012-04-16 09:10 by
基本上来说一个人成熟的机制恐怕是能够让自己能够在不断的磨合当中逐渐消失成见的过程,就一个成熟的那种业绩体系来说,实际上现在的复杂在于业绩对象的那种针对的安全对象的成熟度没有,如果仅仅针对的是一种疯子般的业务来说的业绩或者组织层面来说的业绩,这样的机制成熟的业绩体系是不存在的一个方式。
# re: 消息映射机制的简单实现 回复 更多评论
2012-04-16 09:13 by
实际上业绩组合套拳的组合一定夹杂某一种对于私心认可的范畴内达到的应急范畴内实现对于业绩整个机制的认识,从表面上来看,一旦业绩没有属于自己范围的业绩过程,整个的业绩链被居心叵测的人所掌握,那么业绩机制上面的成熟机制在实现的过程永远被这样或者那样的理由所圈绕。一个成熟的业绩机体本身上面是由于其中业绩机体上面有按照其中规律方式运转的模式旋转,而与时代与行业,和管理它的人就更加没有关系的了
# re: 消息映射机制的简单实现 回复 更多评论
2012-04-16 09:16 by
业绩机制上面的成熟度在于在不断的磨合的组合的过程当中永远不可能按照面上面的业绩组合形成业绩机制过程,业绩机制表明的是在业绩最初形成的时候,需要使用各种各样关于技巧性的使用,一旦业绩成熟,则不过是一种对于业绩形成上面需要依照的规律模式行驶其中业绩机制形成的规律线而已。
# re: 消息映射机制的简单实现 回复 更多评论
2012-04-16 09:19 by
业绩机制形成的规律线绝对不是建立在回复其它层面的上面的不断的 解释层次上面表现出来的那种心安理得局面上面的业绩机制,业绩机制的形成在于自己认为需要付出多少的代价愿意承受这样的一种业绩机制的形成,业绩机制的形成一般是竞争分析--竞争对手分析---柜台分析---赚钱分析---承载风险分析---合理的业绩轨道,这个业绩机制的形成在于一旦在那种对于业绩本身模式不认可,而且浮于人事层面上面是永远不可能体会 到这样的一个业绩机制形成的过程的。
# re: 消息映射机制的简单实现 回复 更多评论
2012-04-16 09:22 by
基于对于业绩机制形成的事实,然后规划属于自身现状的业绩状况就能够发现,充分的运用属于自己的认识与人事与实力来验证对于业绩机制的本身带来的效果,然后再这样的一种效果当中明确这样的一种业绩机制承载出来一个怎么样的自己的体验当中,从而对于自己有一个或者有一种全新的认识的过程,至少在这个过程当中,能够承载属于自己职业生命力的安全模式
# re: 消息映射机制的简单实现 回复 更多评论
2012-04-16 09:25 by
确切的说,业绩机制承载的职业生命力具体表现在属于一种胸襟,没有一种胸襟,格局的诞生恐怕只能够越来越小,胸襟不是以职业生命力的安全作为安全,而恰恰相反,胸襟是站在或者基于职业生命力维护的基础上面去考虑胸襟本身的得失或者愿意承受的东西和不愿意承受的顺应心灵的一种呼唤。
|