战略功能迁移和多重继承 [英] Strategic Functional Migration and Multiple Inheritance

问题描述

我和一些高中学生一直在讨论相关的时间和

，如果
C＃将支持真正的多重继承。 />

与此相关，我想查询C＃社区（此处的''目标''编程

社区）以获得一些社区输入和验证（或不

跟随

两个陈述。


[1]很少有程序员（3％到7％）理解战略功能迁移

（SFM）''（见下面的PS）。


[2]在少数人中，甚至更少（另外3％到7％）是好的战略性

功能性迁移（或0.9％至0.49％）。


这些百分比似乎是正确的吗？ （不到目标的1％

编程

社区在SFM很好）


提前感谢任何相关的质量输入。


Shawnk


PS。


描述战略功能迁移（SFM）在这之后的帖子中

一个。


PPS。我向同学们提交答案（点数差价）确定


[A]少数人的短期有丝分裂，开创了一种新的语言，包括C＃

具有C ++（SFM）功能的生产力


[b]长期社区发展和行业迁移远离C＃作为b $ b核心竞争力的解决方案（微妙的一点）


A / B反过来在编译器

市场中实例化早期采用者模型。
< br $>
PPPS。


我有一个'核心能力''项目我想做的那样会更容易

如果我可以将
与SF＃一起使用SFM。

Some Sr. colleges and I have had an on going discussion relative to when and
if
C# will ever support ''true'' multiple inheritance.

Relevant to this, I wanted to query the C# community (the ''target'' programming
community herein) to get some community input and verify (or not) the
following
two statements.

[1] Few programmers (3 to7%) UNDERSTAND ''Strategic Functional Migration
(SFM)'' (see PS below).

[2] Of those few, even less (another 3 to 7%) are GOOD at Strategic
Functional Migration (or 0.9% to 0.49%).

Do these percentages seem about right? (less than 1% of the target
programming
community are GOOD at SFM)

Thanks ahead of time for any relevant QUALITY input.

Shawnk

PS.

Strategic Functional Migration (SFM) is described in the post following this
one.

PPS. I submit to my fellow colleges that the answer (point spread) determines

[A] Short term mitosis of the few to pioneer a new language incorporating C#
productivity with C++ (SFM) powers

[b] Long term community evolution and industry migration away from C# as a
''core competency'' solution (subtle point)

Both A/B, in turn, instantiate the ''early adopter'' model in the compiler
market.

PPPS.

I have a ''core competency'' project I want to do that would be a lot easier
if I
could use SFM with C#.

推荐答案

续发布：战略功能迁移和多重继承


----定义----

战略功能迁移：SFM


[1]考虑基类的通用功能。


[2]我们通过实现继承（II）

多重继承（MI）功能实现通用功能。


----讨论----

在这篇文章中，我想放弃任何提及''封面''问题



在编译器中实现多重继承。因此，在很长一段时间内关注用户（而不是b
供应商）问题（在战略代码库设计中）。


[微妙点]这个竞争机构代码库的舞台是''核心竞争力''

代码构成了任何企业知识产权驱动的核心（知识产权）

预算支出。因此推断C＃更适合''非核心

能力'代码（软件基础设施，常见内容，UI，一般

商业应用程序）。

核心能力范例将是数据分析（遥测，数据挖掘，高性能数据流，复杂流程和自动化''软件引擎''，

数据探测等）和数据处理。


因此，这篇文章与时间或成本重点项目无关，但

朝向

更复杂的设计（丰富的功能迁移功能）

和''质量'驱动项目。因此，例如，IT绷带编程（不是
为

pejorative）在这里不感兴趣。


（明显：所有项目都有TCQ（'tque'' - 时间，成本，质量） -

战略规划和技术投资是这里的场地和重点。


注意：''True''多重继承（MI）展示两者

（1）实施继承（II）

和

（2）虚拟继承（VI）


见;

http://en.wikipedia.org/wiki/Inherit...mputer_science ）
http://en.wikipedia.org/wiki/Virtual_inheritance
http://en.wikipedia.org/wiki/Multiple_inheritance


INTERF aces为（1）而不是（2）提供语义。

因此，根据定义，接口不支持实现继承

（II）。


见;

http ：//en.wikipedia.org/wiki/Interfa...mputer_science ）


注：关于SFM和''多态替代性'的任何讨论/回应''br />
（多角色entiies - 角色替换 - 接口方面 - 编程

透视 - 正交层次结构）是相关的（和

相关）但未请求。这使得帖子可以在目标编程社区中集中对SFM

意识/无知的响应。


如果你必须回应SFM的优点（我们都是有激情使得

重要

对社区的影响） - 请将您的关键点与

维基百科参考文献中的引用联系起来。这有助于维基百科贡献者（作家）重用你的

参数和

（最终）将你的想法反映回这个目标编程社区。


----摘要 -


在这篇文章之后的帖子中 - 战略功能

mirgration的示例是使用非-GOF模式;


- EOP（事件观察者模式）和

- SMP（状态机模式）


（示例中没有代码 - 只是一个快速的Sr. Architect臀部镜头）


Shawnk

Continued Post : Strategic Functional Migration and Multiple Inheritance

----definition----

Strategic Functional Migration : SFM

[1] Factoring out common functionality to base classes.

[2] Using common functionality via the Implementation Inheritance (II)
feature of Multiple Inheritance (MI).

----discussion----

In this post I would like to forgo any mention of ''under the cover'' issues
when
implementing multiple inheritance in compilers. Thus to focus on user (not
vendor) issues (in ''strategic code library design'') over long periods of time.

[Subtle point] This arena of a comporate ''code base'' is the ''core competency''
code that forms the heart of any corporate IP driven (Intellectual Property)
budget expenditures. Thus infering C# to be more suited to ''non-core
competency'' code (software infrastructure, common stuff, UI, General
Business apps).
Core competency examples would be data analysis (Telemetry, data mining, high
performance data flow, complex process and automation ''software engines'',
data probes, etc.) and data processing.

Thus, this post is not relevant to ''Time'' or ''Cost'' focused projects but
towards
more complex designs (rich functional landscape for functional migration)
and ''Quality'' driven projects. So, for example, IT Bandage programming (not
to be
pejorative) is not of interest here.

(Obvious : All projects have TCQ (''tque'' - Time, Cost, Quality ) -
Strategic planning and technology investment is the venue and focus here)

Note : ''True'' Multiple Inheritance (MI) exhibits both

(1) Implementation Inheritance (II)
and
(2) Virtual Inheritance (VI)

See;

http://en.wikipedia.org/wiki/Inherit...mputer_science)
http://en.wikipedia.org/wiki/Virtual_inheritance
http://en.wikipedia.org/wiki/Multiple_inheritance

Interfaces provide the semantics for (1) but not (2).
Thus interfaces, by definition, do not support implementation inheritance
(II).

See;

http://en.wikipedia.org/wiki/Interfa...mputer_science)

Note : Any discussions/responses on SFM and ''polymorphic substituability''
(multi-role entiies - role substituion - interface aspect - programming
perspective - orthogonal hierarchies) ARE related (and
relevant) but NOT requested. This allows the post to focus responses on SFM
awareness/ignorance in the target programming community.

If you must respond on the merit of SFM (we all have passion that makes
significant
impact on the community) - please relate your key points to quotes from the
wikipedia references. This helps Wikipedia contributors (writers) reuse your
arguments and
(eventually) reflect your ideas back into this target programming community.

----summary--

In the post following this post - an example of ''strategic functional
mirgration'' is given using non-GOF patterns;

- EOP (Event Observer Pattern) and
- SMP (State Machine pattern)

(no code in example - just a quick Sr. Architect hip shot)

Shawnk

续帖：战略功能迁移和多重继承


战略功能迁移示例：SFM


Event_Recorder，Event_log，Event_Viewer


模式[b] - 状态机----------：机器， Switch，Map，------------

State_Recorder， State_log，State_Viewer


常见的日志记录/记录器代码已被考虑在内。


新的记录器模式是为历史，日志等而形成 - 包括。


项目，日志，记录器，查看器，活页夹（将基本角色绑定到一起

' 'logger''实体 - （模式阶段））


----代码重用结果通过II（实现继承）-------

模式A / B使用基于< _itm_typ>的通用记录器实体。 as

_Evt_typ / _Sta_typ


====虚拟继承的关键差异（接口）VS实施

继承=== =======


模式A / B记录器角色仍然可以从其他基本类中继续使用


-----关键点定义------------------


SFM（战略功能迁移）需要功能正交

''复制代码''的分解。


分解不得影响或要求预先存在（预分解）基础

类继承更改。 />

-----关键点示例---（前/后分解）---


II =实施继承

MI =多重继承

VI =虚拟继承


预分解模式A / B

- 两者都有一个基于Tracer调试模式的'debug / tracer''基类


Post Decomp Pattern A / B


With II ...... 。


Tracer和Logger模式是分开的并保持功能正交


没有II使用VI（如在C＃中）.... />

Tracer和Logger模式必须合并，然后继承为''超级

记录器，带有跟踪''实体


------核心能力代码点--------------


核心能力代码的功能正交性质要求''混合

和

匹配核心角色模型（模式参与者），它提供了核心功能的核心功能（IP - 知识产权。


因此（因此）SFM（战略功能迁移）是唯一可能

与

MI / II语言特征。


注：提出''Mixins和其他人为的解决方法'的论据（作为对II的替代SFM机制的

）证明了无知提议者：


（A）SFM本身

（B）比较不同SFM机制的分析指标

（C）不同SFM机制的正式比较分析


此类SFM实施论证（或响应）的前提是点差的非正式指标（目标社区无知的水平）

相对于SFM，核心竞争力，战略投资，知识产权（知识产权）和其他执行工程水平问题。


Shawnk


PS 。我个人承认，记录器/跟踪实体（上图）整合

方法（SFM等）可以争论（MI-II不需要，

VI-SII很好）。


为了扩展这一点并争辩说（因此也是如此）所有实体都可以是

集成到SUPER实体中是不正确的。一切都会最终成为一个

big

超级实体。


这些论据基于不理解II，SFM，功能

正交性，MI

和战略代码重用。


最终，所有''超实体''代码重用参数都是建立在无知的基础上



SFM并且在没有这种无知的情况下不能（逻辑上）存在。


PPS。


由于这些论点（SUPER-entities）在社区中普遍存在，因此我们可以推断出这些论点是由b / b
''expert''/ b $ b专家组成的。目标编程社区是;


[1]主要不知道''战略功能迁移''（SFM）

（和/或）

[2]目标社区尚未发展到认可SFM和

''移动到支持它的语言'。

OR

[3] SFM（战略功能迁移）不是固有/可取的

p henomena /代码重用机制


所以：if [3]然后[1]和/或[2]


务实/真实世界/逻辑环绕是;


[1]无知：结果是实用的（但理论上不是真的）[3]

[2]进化：基于[3]在理论上（客观上）是真实的，实用的（和 - 理论上是真的）[3]

。


论证的逻辑核心焦点是：


[X]主观：编程社区对SFM作为''模式的理解

重构机制''


[Y]目标：继承效用和结构现实（客观事实）

的SFM作为'模式重构机制''


因此关于进入这个讨论的问题，


" SFM中目标社区的百分比是多少？


投影：基于其他（非II）机制争论SFM最终是试图显示[1]或证明[3]


---------------


警告：[2-B] - ......转到langague


当前没有（生产准备 - 黄金时间）语言支持C语言，C＃生产力和C ++ II（我们可以同意:-)。如果

是

（这种语言）那么，可以说，社区已经发展了

$>
并且只是在等待迁移到的解决方案。如果有人知道这种

语言，请回复（Efiel等）。

Continued Post : Strategic Functional Migration and Multiple Inheritance

Example of ''Strategic Functional Migration'' : SFM

Pattern [A] - Extended Event Observer : Client, Subject, Observer, Binder,
Event_Recorder, Event_log, Event_Viewer

Pattern [b] - State Machine ----------: Machine, Switch, Map, ------------
State_Recorder, State_log, State_Viewer

The common ''logging/logger'' code is factored out.

A new ''Logger Pattern'' is formed for histories, logs, etc. - which includes.

Item, Log, Recorder, Viewer, Binder (to bind base roles together into a
''logger'' entity - (pattern stage))

---- code reuse result via II (Implementation Inheritance) -------

Patterns A/B use a generic ''logger'' entity based on <_itm_typ> as
_Evt_typ/_Sta_typ

==== KEY DIFFERENCE OF VIRTUAL INHERITANCE (intefaces) VS IMPLEMENTATION
INHERITANCE ==========

Pattern A/B logger roles can STILL INHERIT from other ESSENTIAL BASE CLASSES

----- Key point by definition ------------------

SFM (Strategic Functional Migration) requires functionally orthogonal
decomposition of ''replicated code''.

Decomposition must not effect or require pre-existing (pre decomposition) base
class inheritance changes.

----- Key point example ---(pre/post decomp) ---

II = Implementation Inheritance
MI = Multiple Inheritance
VI = Virtual Inheritance

Pre Decomp Pattern A/B

- Both had a ''debug/tracer'' base class based on a Tracer debug pattern

Post Decomp Pattern A/B

With II ....

Tracer and Logger patterns are separate and remain functionally orthogonal

Without II using VI (as in C#) ....

Tracer and Logger patterns must be combined and then inherited as a ''super
logger with tracing'' entity

------ core competency code point --------------

The functionally orthogonal nature of core competency code requires the ''mix
and
match'' of the core role models (pattern participants) which provide the
functional archetypes of the core functions (the IP - Intellectual property).

Thus (and therefore) SFM (Strategic Functional Migration) is ONLY possible
with
MI/II language features.

Note : Arguments proposing ''Mixins and other contrived workarounds'' (as an
alternative SFM mechanism to II) prove the ignorance of the proposer in:

(A) SFM itself
(B) analytical metrics comparing different SFM mechanisms
(C) Formal comparative analysis of different SFM mechanisms

The prevelance of such SFM implementation arguments (or responses) is an
informal indicator of the point spread (level of target community ignorance)
relative to SFM, core competency, strategic investment, IP (intellectual
property) and other executive engineering level issues.

Shawnk

PS. Personally I concede that the logger/trace entity (above) integration
approach (SFM, etc) can be argued (MI-II not needed,
VI-SII is fine).

To extend this and argue that (thus and therefore) ALL entities can be
integrated into SUPER-entities is incorrect. Everything would end up as one
big
super entity.

Such arguments are based on not understanding II, SFM, functional
orthogonality, MI
and strategic code reuse.

Ultimately, all ''super-entity'' code reuse arguments are founded on ignorance
of
SFM and can not (logically) exist without this ignorance.

PPS.

Since such arguments (SUPER-entities) are prevalent in the community by
''expert''
pundits, we can infer that the target programming community is;

[1] Predominantly ignorant of ''Strategic Functional Migration'' (SFM)
(and/or)
[2] The target community has not evolved to the point of recognizing SFM AND
''moved to a language'' that supports it.
OR
[3] SFM (Strategic Functional Migration) is not an inherent/desirable
phenomena/mechanism of code reuse

So: if [3] then [1] and/or [2]

The pragmatic/real world/logical wrap around is;

[1] Ignorance : results in the pragmatic (but not theoretically true) [3]
[2] Evolution : results in the pragmatic (and --- theoretically true) [3]

based on [3] being theoretically (objectively) true.

The logical ''core focal point'' of the argument is:

[X] Subjective : Programming community understanding of SFM as a ''pattern
refactor mechanism''

[Y] Objective : Inherient utility and structural reality (objective truth)
of SFM as a ''pattern refactor mechanism''

Thus the question on entry to this discussion,

" What percentage of the target community is GOOD at SFM? "

Projection : To argue SFM based on other (non-II) mechanisms is ultimately
an attempt to display [1] or prove [3]

---------------

Caveat : [2-B] - ...moved to a langague

CURRENTLY there is no (production ready - prime time) language that supports C
like syntax, C# productivity and C++ II (that we can agree on :-). If there
was
(such a language) then, it can be argued, that the community has already
evolved
and merely waiting for a solution to migrate to. If any one knows of such a
language please respond (Efiel, etc).

我很想知道你是怎么来的你在第1点和第2点有
的数字。


虽然我同意实现继承会有用，如果

您声称的数字接近正确，您已经回答了

为什么现代语言不支持MI（意味着大多数.NET语言，

Java）。


在所有这些中，我没有看到关于如何在C＃中包含此类功能的建议（建议的语言语法，规则等等） 。为什么

没有显示那种性质？

-

- Nicholas Paldino [.NET / C＃MVP]

- mv*@spam.guard.caspershouse.com


" Shawnk" <嘘**** @ discussions.microsoft.com>在消息中写道

news：37 ********************************** @ microsof t.com ...

I would be interested in knowing how you came to the numbers that you
have in points 1 and 2.

While I agree that implementation inheritance would be useful, if the
numbers that you claim are anywhere near correct, you have already answered
why MI is not supported in modern languages (meaning most .NET languages,
Java).

In all of this, I didn''t see a recommendation on how such functionality
might be included in C# (proposed language syntax, rules, etc, etc). Why
not show something of that nature?
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Shawnk" <Sh****@discussions.microsoft.com> wrote in message
news:37**********************************@microsof t.com...

有些高级学院和我有关于什么时候进行讨论
和
如果C＃将支持''真的''多重继承。

与此相关，我想查询C＃社区（此处的''目标''
编程社区）以获得一些社区输入和验证（或不）
以下两个陈述。

[1]很少有程序员（3％到7％）理解战略功能迁移（SFM） （见下面的PS）。

[2]在少数人中，甚至更少（另外3％至7％）在战略性功能迁移（或0.9％至0.49％）中表现良好。 br />
这些百分比看起来是对的吗？ （不到1％的目标
编程社区在SFM很好）

提前感谢任何相关的质量输入。

Shawnk

PS。

战略功能迁移（SFM）描述在
这个
之后的帖子中。

PPS 。我向同学们提交了答案（点数传播）
确定

[A]少数人的短期有丝分裂，开创了一种新的语言，包含了C＃
具有C ++（SFM）功能的生产力

[b]长期社区发展和行业迁移远离C＃作为核心竞争力解决方案（微妙点）
<反过来，两个A / B都会在编译器市场中实例化早期采用者模型。

PPPS。

我有一个''核心能力''项目我希望这样做会更容易
如果我可以在SF＃中使用SFM。

Some Sr. colleges and I have had an on going discussion relative to when
and
if
C# will ever support ''true'' multiple inheritance.

Relevant to this, I wanted to query the C# community (the ''target''
programming
community herein) to get some community input and verify (or not) the
following
two statements.

[1] Few programmers (3 to7%) UNDERSTAND ''Strategic Functional Migration
(SFM)'' (see PS below).

[2] Of those few, even less (another 3 to 7%) are GOOD at Strategic
Functional Migration (or 0.9% to 0.49%).

Do these percentages seem about right? (less than 1% of the target
programming
community are GOOD at SFM)

Thanks ahead of time for any relevant QUALITY input.

Shawnk

PS.

Strategic Functional Migration (SFM) is described in the post following
this
one.

PPS. I submit to my fellow colleges that the answer (point spread)
determines

[A] Short term mitosis of the few to pioneer a new language incorporating
C#
productivity with C++ (SFM) powers

[b] Long term community evolution and industry migration away from C# as a
''core competency'' solution (subtle point)

Both A/B, in turn, instantiate the ''early adopter'' model in the compiler
market.

PPPS.

I have a ''core competency'' project I want to do that would be a lot easier
if I
could use SFM with C#.

这篇关于战略功能迁移和多重继承的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！