decoupling意思:解耦。
短语搭配:
decouple principle 解耦原理;fuzzy decouple 模糊解耦;decouple beams 解耦梁;effect decouple 效果解耦;voltage decouple 电压型解耦;decouple charge 不耦合装药。
Geometric decouple 几何解耦;static decouple 静态解耦;noises decouple 噪声解耦。
相关例句:
1、It focuses on the positioning of decoupling inventory.。
它专注于解耦库存的位置。
2、Design patterns for decoupling.。
用于去耦合的设计模式。
3、You might even call it decoupling.。
也许这也是一种脱钩吧。
4、Decoupling interface and implementation.。
解除耦合界面以及执行方案。
5、Decoupling UI code from business logic.。
分解业务逻辑和UI代码。
解耦
[词典] [化] decoupling; 。
[例句]实现了对具有任意延时结构的多变量系统的解耦控制。
It realizes self-tuning decoupling control for multivariable systems with arbitary delay time structure.。
用数学方法将两种运动分离开来处理问题,常用解耦方法就是忽略或简化对所研究问题影响较小的一种运动,只分析主要的运动。
数学中解耦是指使含有多个变量的数学方程变成能够用单个变量表示的方程组,即变量不再同时共同直接影响一个方程的结果,从而简化分析计算 选择适当的控制规律将一个多变量系统化为多个独立的单变量系统的控制问题。
在解耦控制问题中,基本目标是设计一个控制装置,使构成的多变量控制系统的每个输出变量仅由一个输入变量完全控制,且不同的输出由不同的输入控制。
扩展资料:
完全解耦控制:对于输出和输入变量个数相同的系统,如果引入适当的控制规律,使控制系统的传递函数矩阵为非奇异对角矩阵,就称系统实现了完全解耦。
静态解耦控制:一个多变量系统在单位阶跃函数(见过渡过程) 输入作用下能通过引入控制装置实现稳态解耦时,就称实现了静态解耦控。
软件解耦:说起软件的解耦必然需要谈论耦合度,降低耦合度即可以理解为解耦,模块间有依赖关系必然存在耦合,理论上的绝对零耦合是做不到的,但可以通过一些现有的方法将耦合度降至最低。
脱钩原指火车车厢的挂钩脱落,引申为事物的联系中断。
脱是一个汉字,读作tuō,本意是指取下,除去,掉下,落掉等。
钩,gōu,悬挂或探取东西用的器具,形状弯曲,头端尖锐。
脱钩简单的说就是阐述依赖关系不是长久如此的,经过时间的演变,A与B之间就不再存在依赖关系。比如:我们一直保持环保的循环经济模式,经过一段漫长的时间以后,经济发展就不再危害环境保护了,他们之间就实现了脱钩。
在描述新兴市场的投资机会,很多人常会引用“脱钩”理论。这种理论认为,新兴市场在经历最近几年的发展之后,区内的政治体制、经济基础以及企业质量都有了较大改善,加上在天然资源和人口因素等方面的优势,新兴经济的增长已经不再需要依赖欧美成熟市场,亦即有能力与欧美的经济走势实现“脱钩”。
脱钩理论的含义:
脱钩(decoupling)理论是经济合作与发展组织(OECD)提出的形容阻断经济增长与资源消耗或环境污染之间联系的基本理论,20世纪末,OECD将脱钩概念引入到农业政策研究,并逐步拓展到环境等领域。以“脱钩”这一术语表示二者关系的阻断,即使得经济增长与资源消耗或环境污染脱钩,实现二者脱钩发展。
根据环境库兹涅茨曲线(EKC)假说,经济的增长一般带来环境压力和资源消耗的增大,但当采取一些有效的政策和新的技术时,可能会以较低的环境压力和资源消耗换来同样甚至更加快速的经济增长,这个过程被称为脱钩。
此文转载的。觉得非常精辟。希望对正在学面向对像设计的你有所帮助,总的说来。有这么多设计模式,要用面向对像。都是为了解耦。力在降低各模块的依赖,提高重用。>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 在程序设计过程中,最头痛的不是逻辑的编写过程,更不是算法的设计,最头痛的是如何设计出一个容易维护,扩展性好的东西。而耦合问题是最令人烦躁的,它的存在很多人发现不了,所以往往无从入手,真是有苦自己知了,呵呵。以下是我的经验之谈。我通过例子来体现耦合问题的影响。第一个例子: 在开发游戏的时候,有很多实体类,通常属于一条相同的生产线,如地形:土地,石块,草地,雪地,沼泽,等,具有相同特征而功能不同的对象,新手们,一般是在程序的某个地方,默默地new出这些应用到的对象,恩,一个,两个,三个,慢慢你会发现程序中不断出现新对象,如果存在10对象实体,而对象的提供了5个接口函数,也就是,读写操作,在程序中出现了几十次,这时,我不要这个对象了,换成其他了,那你是不是要改几十处地方?恩,问题就是这里了,没有一个抽象层面,必然会导致维护困难,当对象扩大化到100个,这是一个维护噩梦,当然,单单一个抽象层面是无法解决new实体对象的事实的,这个是令人头痛的问题,管理对象的生产是一个很重要的模块,这里对于某些高级语言,如C++,唯一比较好缓解的是工厂模式中的工厂方法,我比较喜欢用这个模式去管理对象,简单工厂就不要学了,没什么实际意义,而我可以很明确告诉你,第一个带你入门,第一个让你打开眼界的模式绝对是工厂方法模式,如果真想学学模式,请先研究工厂方法,其使用的意义在于把对象的生成延迟到子类,而统一使用接口去管理对象的初始化,把变化点分离出调用端,这里我只能告诉你为什么要用设计模式,什么情况下要用,理不理解就靠你自己的实际经验和悟性了,本人悟性不高,当时在学习设计模式的时候,看了很多次依然没有领悟到工厂模式的奥妙,直至代码量和项目经验不断地增加才顿悟出过中道理,确实是很难用文字来表达,不过以上的例子足够证明它的意义,根源都是为了解耦。第二个例子: 由于我一直都在开发游戏,所以所举得例子不免都和游戏有关,这个例子,如果你写过一个完整的游戏,必然有所了解,游戏总会有界面,而其中比较典型的界面是,菜单界面,菜单里有按钮,对吧?恩,这个问题,我当时设计就考虑,菜单类和按钮类究竟是分开还是合在一起?想来想去,由于当时设计观念没到家,最后把它们合在一起了,这种做法绝对是不好的,为什么呢?我们不要从概念上入手解释,通俗的讲法就是,菜单和按钮的对应关系是一对多,对吧?没有一种固定的关系,有可能1对2,1对3,1对10等等,所以把它们写在一起,是很僵化的,就单凭这种证明就可以发现,它们要分开,而它们最后的表现是合在一起,通过组合的方式,把按钮的抽象层面注入到菜单里面,就可以动态地生成完整的菜单,所谓的组合方式,不就是,菜单里面有一个存放按钮引用的集合,希望你明白我所说的,具体我就不解释了。 结语:我认为这里是全篇文章最重要的,比任何所谓的分层理论都重要,因为它更通俗,更实际,很多人,并不是面向对象学得不好,但总觉得差什么,我也经历过,面向对象,封装,多态,继承,学过的人都知道,都认为自己了解了,其实不然,很多很奇妙的因素,让你误解了,大部分的人认为封装很简单,其实大错特错了,封装是最奇妙的,也是最难用好的。只要你记住以下原则,必然能很好地用好封装,成员尽量使用protected和private,不要去使用public.尽量不要提供给外部对成员属性getter的接口,意思就是不要暴露成员,为什么要这样呢?很简单,暴露成员属性必然会导致自身业务的外泄,业务外泄,会导致,类之间的无谓耦合,如A类有成员a,而程序需要对a数据改变,而你提供一个B类可以访问a成员的getter接口,B类在其自身对a修改,看上去没什么,实际上,就是类耦合,对a的修改是类A的职务,由于习惯的提供getter,导致了,在写类B的时候错误地添加了修改业务,使类A内聚能力降低,程序逐步庞大必然会越发明显,真所谓牵一发动全身,小程序确实是很难看出问题所在。就写那么多,本人愚见,希望对你有帮助。