战略功能迁移和多重继承

模式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 InheritanceExample of ''Strategic Functional Migration'' : SFMPattern [A] - Extended Event Observer : Client, Subject, Observer, Binder,Event_Recorder, Event_log, Event_ViewerPattern [b] - State Machine ----------: Machine, Switch, Map, ------------State_Recorder, State_log, State_ViewerThe 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 IMPLEMENTATIONINHERITANCE ==========Pattern A/B logger roles can STILL INHERIT from other ESSENTIAL BASE CLASSES----- Key point by definition ------------------SFM (Strategic Functional Migration) requires functionally orthogonaldecomposition of ''replicated code''.Decomposition must not effect or require pre-existing (pre decomposition) baseclass inheritance changes.----- Key point example ---(pre/post decomp) ---II = Implementation InheritanceMI = Multiple InheritanceVI = Virtual InheritancePre Decomp Pattern A/B- Both had a ''debug/tracer'' base class based on a Tracer debug patternPost Decomp Pattern A/BWith II ....Tracer and Logger patterns are separate and remain functionally orthogonalWithout II using VI (as in C#) ....Tracer and Logger patterns must be combined and then inherited as a ''superlogger with tracing'' entity------ core competency code point --------------The functionally orthogonal nature of core competency code requires the ''mixandmatch'' of the core role models (pattern participants) which provide thefunctional archetypes of the core functions (the IP - Intellectual property).Thus (and therefore) SFM (Strategic Functional Migration) is ONLY possiblewithMI/II language features.Note : Arguments proposing ''Mixins and other contrived workarounds'' (as analternative 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 mechanismsThe prevelance of such SFM implementation arguments (or responses) is aninformal indicator of the point spread (level of target community ignorance)relative to SFM, core competency, strategic investment, IP (intellectualproperty) and other executive engineering level issues.ShawnkPS. Personally I concede that the logger/trace entity (above) integrationapproach (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 beintegrated into SUPER-entities is incorrect. Everything would end up as onebigsuper entity.Such arguments are based on not understanding II, SFM, functionalorthogonality, MIand strategic code reuse.Ultimately, all ''super-entity'' code reuse arguments are founded on ignoranceofSFM 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/desirablephenomena/mechanism of code reuseSo: 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 ''patternrefactor 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 ultimatelyan attempt to display [1] or prove [3]---------------Caveat : [2-B] - ...moved to a langagueCURRENTLY there is no (production ready - prime time) language that supports Clike syntax, C# productivity and C++ II (that we can agree on :-). If therewas(such a language) then, it can be argued, that the community has alreadyevolvedand merely waiting for a solution to migrate to. If any one knows of such alanguage 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 youhave in points 1 and 2.While I agree that implementation inheritance would be useful, if thenumbers that you claim are anywhere near correct, you have already answeredwhy 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 functionalitymight be included in C# (proposed language syntax, rules, etc, etc). Whynot show something of that nature?--- Nicholas Paldino [.NET/C# MVP]- mv*@spam.guard.caspershouse.com"Shawnk" <Sh****@discussions.microsoft.com> wrote in messagenews: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＃作为核心竞争力解决方案（微妙点） 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#. 这篇关于战略功能迁移和多重继承的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！