Switch-Case与Polymorphism场景

Switch-Case与Polymorphism场景

问题描述:

多态性替换switch语句,使代码更多

紧凑/可读/可维护/ OO无论如何,好吧!


我的理解,这需要在编程级别完成,这是:b $ b这个:


a switch-case有一个变量(很可能是一个枚举)&

相关符号或整数值。根据变量所持有的b $ b符号/值进行选择。所以


变量= VALUE1; //选择1

....

变量= VALUE2; //选择2

....

switch(变量){

case VALUE1:DoForValue1();休息;

案例VALUE2:DoForValue2();打破;

}


用多态替换它,变量substitue是pointerToBase

&符号/值替换是''DerivedClass'的实例化,例如,


pointerToBase = new DerivedClass1; //选择1

....

pointerToBase = new DerivedClass2; //选择2

....

pointerToBase-> DoAccordingToDerivedClass(); //虚拟通话!开关

不需要


让我们用另一种观点来看待它,即选择这个

的来源!两个问题:


1 - 如果选择源是一组无线电按钮&用户

选择&多次重新选择不同的无线电,切换

场景。并没有太大影响,但对于多形体。场景"我们

必须是新的&删除各种派生类很多时间,它就像玩内存一样(特别是如果Derived Objects

占用大量内存,那就非常糟糕)。有没有合适的替代品?


2 - 我们可以轻松地将变量值保留在切换场景中,

再次加载它&应用另一个开关。对于多晶型物。方案,

持久很容易,调用pointerToBase-> PersistAccToDerivedClass();

但是对于加载我们必须应用''switch语句'',因为

持久化对象只是一个字符串或整数值

识别不同的derivedObjects,如何避免切换语句

此时?

Polymorphism replaces switch statements, making the code more
compact/readable/maintainable/OO whatever, fine!

What I understand, that needs to be done at the programming level, is
this:

a switch-case has a variable (most probably an enumeration) &
associated symbols or integral value. Selection is made, base on what
symbol/value the variable holds. So

variable = VALUE1; // selection 1
....
variable = VALUE2; // selection 2
....
switch (variable) {
case VALUE1: DoForValue1(); break;
case VALUE2: DoForValue2(); break;
}

to replace it w polymorphism, the variable substitue is pointerToBase
& symbol/value substitute is ''an instantiation of DerivedClass'', e.g.,

pointerToBase = new DerivedClass1; // selection 1
....
pointerToBase = new DerivedClass2; // selection 2
....
pointerToBase->DoAccordingToDerivedClass(); // virtual-call! switch
not needed

Lets look at it with another perspective, i.e., the source of that
selection! Two questions:

1 - If the selection-source is some set of radio-buttons & User
selects & reselects different radios multiple times, the "switch
scenario" doesn''t get much effected, but for "polymorph. scenario" we
have to new & delete the various derived classes that much time, it''s
like playing with memory (pretty bad particularly if Derived Objects
take-up large memory). Is there any decent substitute?

2 - We can easily persist the variable value in the "switch scenario",
load it again & apply another switch. For "polymorph. scenario",
persisting is easy, call pointerToBase->PersistAccToDerivedClass();
but for loading we have to apply a ''switch statement'' because the
persisted object would be just a character-string or integral value
identifying different derivedObjects, how to avoid a switch statement
at this time?

Myster Ious< yo ***************** @ yahoo.com>在消息中写道

新闻:5d ************************** @ posting.google.c om ...
Myster Ious <yo*****************@yahoo.com> wrote in message
news:5d**************************@posting.google.c om...
Polymorphism取代了switch语句,使得代码更紧凑/可读/可维护/ OO无论如何,很好!


我想你可以用switch语句来表达多态性,但

并不意味着你应该用
虚拟电话。

我的理解,需要在编程层面完成,这是:

一个开关盒具有变量(最可能是枚举)&
相关符号或整数值。根据变量所具有的符号/值来进行选择。所以

变量= VALUE1; //选择1
...
变量= VALUE2; //选择2
...
开关(变量){
情况VALUE1:DoForValue1();破坏;
案例VALUE2:DoForValue2();打破;

取代它w多态,变量substitue是pointerToBase
&符号/值替换是''DerivedClass'的实例化,例如,

pointerToBase = new DerivedClass1; //选择1
...
pointerToBase = new DerivedClass2; //选择2
...
pointerToBase-> DoAccordingToDerivedClass(); //虚拟通话!开关
不需要

让我们用另一个视角来看待它,即选择的来源!两个问题:

1 - 如果选择源是一组无线电按钮&用户
选择&多次重新选择不同的无线电,切换场景和切换场景。并没有太大影响,但对于多形体。场景&QUOT;我们需要新的&很长一段时间删除各种派生类,就像玩内存一样(特别是如果派生对象占用大量内存,那就非常糟糕)。有没有合适的替代品?


是的,原始开关是完美的。

2 - 我们可以轻松地将变量值保留在切换方案中,
加载再一次&应用另一个开关。对于多晶型物。方案,
持久化很容易,调用pointerToBase-> PersistAccToDerivedClass();
但是为了加载我们必须应用''switch语句'',因为
持久化对象只是一个字符串或整数值
识别不同的derivedObjects,如何避免切换语句
此时?
Polymorphism replaces switch statements, making the code more
compact/readable/maintainable/OO whatever, fine!
I suppose you can express polymorphism in terms of switch statements, but
that doesn''t mean you should replace all your switch statements with a
virtual call.
What I understand, that needs to be done at the programming level, is
this:

a switch-case has a variable (most probably an enumeration) &
associated symbols or integral value. Selection is made, base on what
symbol/value the variable holds. So

variable = VALUE1; // selection 1
...
variable = VALUE2; // selection 2
...
switch (variable) {
case VALUE1: DoForValue1(); break;
case VALUE2: DoForValue2(); break;
}

to replace it w polymorphism, the variable substitue is pointerToBase
& symbol/value substitute is ''an instantiation of DerivedClass'', e.g.,

pointerToBase = new DerivedClass1; // selection 1
...
pointerToBase = new DerivedClass2; // selection 2
...
pointerToBase->DoAccordingToDerivedClass(); // virtual-call! switch
not needed

Lets look at it with another perspective, i.e., the source of that
selection! Two questions:

1 - If the selection-source is some set of radio-buttons & User
selects & reselects different radios multiple times, the "switch
scenario" doesn''t get much effected, but for "polymorph. scenario" we
have to new & delete the various derived classes that much time, it''s
like playing with memory (pretty bad particularly if Derived Objects
take-up large memory). Is there any decent substitute?
Yes, the original switch is perfect.
2 - We can easily persist the variable value in the "switch scenario",
load it again & apply another switch. For "polymorph. scenario",
persisting is easy, call pointerToBase->PersistAccToDerivedClass();
but for loading we have to apply a ''switch statement'' because the
persisted object would be just a character-string or integral value
identifying different derivedObjects, how to avoid a switch statement
at this time?




我不知道。字符串和函数指针的映射怎么样?

函数指针数组怎么样? (对于积分值的情况)毫无疑问

各种方法。你甚至可能会发现一个开关做了很好的工作。


这是一个功课问题还是你只是沉思?
>
DW



I don''t know. How about a map of strings and function pointers? How about an
array of function pointers? (for the integral value case) There are no doubt
all sorts of methods. You might even find that a switch does an excellent
job.

Is this a homework question or are you just musing?

DW


David White写道:
David White wrote:
我想你可以表达多态性切换语句,但
并不意味着你应该用虚拟调用替换所有的switch语句。


只有那些简化,因为它们增加了灵活性。

这是一个功课问题还是你只是沉思?
I suppose you can express polymorphism in terms of switch statements, but
that doesn''t mean you should replace all your switch statements with a
virtual call.
Only the ones that simplify as they add flexibility.
Is this a homework question or are you just musing?




这是一个常见问题,因为学习路径。为了解释多态性,我们必须解释它是如何与它相反的可互换的。然后学习者去,并且b $ b试图找到它不起作用的情况。学习者并不经常熟悉程序的内部引擎,其中范例简化了b
,但他们通常熟悉边界情况,例如

具有固定常数的GUI。


-

Phlip
http://clublet.com/c/c/why?ZenoBuddhism

- 询问我们的风险投资 b $ b点火外包服务 -



It''s a FAQ because of the learning path. To explain polymorphism, we must
explain how it''s interchangable with its opposite. Then the learner goes and
tries to find the situations where it doesn''t work. Learners are not often
familiar with the internal engines of programs, where the paradigm
simplifies, but they are often familiar with boundary situations such as
GUIs with fixed constants.

--
Phlip
http://clublet.com/c/c/why?ZenoBuddhism
-- Ask about our Venture Capital
ignition outsourcing services --


Myster Ious写道:
Myster Ious wrote:
Polymorphism取代了switch语句,代码更多
紧凑/可读/可维护/ OO无论如何,很好!


多态性的目的是*不*来取代切换声明。

您的整个帖子都是基于错误的假设。我建议你研究一下

面向对象的设计。


多态性可以用switch语句和运行时完成

类型信息,但这样的安排非常混乱,更难以维持,而且效率可能更低。

我所理解的,需要在编程水平,这是:

一个switch-case有一个变量(很可能是一个枚举)&
相关的符号或整数值。根据变量所具有的符号/值来进行选择。所以

变量= VALUE1; //选择1
...
变量= VALUE2; //选择2
...
开关(变量){
情况VALUE1:DoForValue1();破坏;
案例VALUE2:DoForValue2();打破;

替换它w多态,变量替换是pointerToBase
&符号/值替换是''DerivedClass'的实例化,例如,

pointerToBase = new DerivedClass1; //选择1
...
pointerToBase = new DerivedClass2; //选择2


如果你不想删除pointerToBase,那么你有一个内存

泄漏。

...
pointerToBase-> DoAccordingToDerivedClass(); //虚拟通话!开关
不需要

让我们用另一个视角来看待它,即选择的来源!两个问题:

1 - 如果选择源是一组无线电按钮&用户
选择&多次重新选择不同的无线电,切换场景和切换场景。并没有太大影响,但对于多形体。场景&QUOT;我们需要新的&很长一段时间删除各种派生类,就像玩内存一样(特别是如果派生对象占用大量内存,那就非常糟糕)。有没有合适的替代品?


我很难相信任何有能力的程序员都会以这种方式编写代码

。一种更可能的方式是单击按钮的状态

一旦根据它采取某些行动就会被检查,例如

当用户点击确定按钮按钮。即使这样,所采取的行动也不必分配多态对象。基于按钮状态的选择

语句可能更合适。

2 - 我们可以轻松地将变量值保留在切换方案中,持久化很容易,调用pointerToBase-> PersistAccToDerivedClass();
但是为了加载我们必须应用''switch语句'',因为
持久化对象只是一个字符串或整数值
识别不同的derivedObjects,如何避免在此时切换语句?
Polymorphism replaces switch statements, making the code more
compact/readable/maintainable/OO whatever, fine!
The purpose of polymorphism is *not* to replace "switch" statements.
Your entire post is based on a faulty assumption. I suggest you study
object-oriented design a bit more.

Polymorphism can be accomplished with switch statements and run-time
type information, but such an arrangement is incredibly messy, much more
difficult to maintain, and probably less efficient.

What I understand, that needs to be done at the programming level, is
this:

a switch-case has a variable (most probably an enumeration) &
associated symbols or integral value. Selection is made, base on what
symbol/value the variable holds. So

variable = VALUE1; // selection 1
...
variable = VALUE2; // selection 2
...
switch (variable) {
case VALUE1: DoForValue1(); break;
case VALUE2: DoForValue2(); break;
}

to replace it w polymorphism, the variable substitute is pointerToBase
& symbol/value substitute is ''an instantiation of DerivedClass'', e.g.,

pointerToBase = new DerivedClass1; // selection 1
...
pointerToBase = new DerivedClass2; // selection 2
If you didn''t bother to delete pointerToBase, then you have a memory
leak here.
...
pointerToBase->DoAccordingToDerivedClass(); // virtual-call! switch
not needed

Lets look at it with another perspective, i.e., the source of that
selection! Two questions:

1 - If the selection-source is some set of radio-buttons & User
selects & reselects different radios multiple times, the "switch
scenario" doesn''t get much effected, but for "polymorph. scenario" we
have to new & delete the various derived classes that much time, it''s
like playing with memory (pretty bad particularly if Derived Objects
take-up large memory). Is there any decent substitute?

I have a hard time believing any competent programmer would write code
this way. A more likely way would be for the state of the radio button
set to be examined once it''s time to take some action based on it, e.g.
when the user clicks the "OK" button. Even then, the action taken
doesn''t have to be allocating a polymorphic object. A selection
statement based on the state of the buttons may be much more appropriate.
2 - We can easily persist the variable value in the "switch scenario",
load it again & apply another switch. For "polymorph. scenario",
persisting is easy, call pointerToBase->PersistAccToDerivedClass();
but for loading we have to apply a ''switch statement'' because the
persisted object would be just a character-string or integral value
identifying different derivedObjects, how to avoid a switch statement
at this time?




它还有更多通常有一组多态对象,并依次将一些

虚函数应用于集合中的每个对象。这个想法你似乎有分配,使用,扔掉和重复的意思。很奇怪,

可能反映了一个糟糕的设计。


-Kevin



It''s far more common to have a set of polymorphic objects and apply some
virtual function to each object in the set in turn. This idea you seem
to have of "allocate, use, throw away, and repeat" is very odd, and
would probably reflect a poor design.

-Kevin