为什么紧密耦合不好但强类型好? [英] Why is tightly coupled bad but strongly typed good?

查看:167
本文介绍了为什么紧密耦合不好但强类型好?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在努力查看松耦合代码的实际好处.为什么要花费大量的精力使某些东西可以灵活地与其他各种对象一起使用?如果您知道需要实现什么,为什么不为此专门编写代码?

I am struggling to see the real-world benefits of loosely coupled code. Why spend so much effort making something flexible to work with a variety of other objects? If you know what you need to achieve, why not code specifically for that purpose?

对我来说,这类似于创建无类型变量:这使它非常灵活,但由于可能传入了意外值而使自己面临问题.这也使它难以阅读,因为您不明确地知道什么是什么.被传递.

To me, this is similar to creating untyped variables: it makes it very flexible, but opens itself to problems because perhaps an unexpected value is passed in. It also makes it harder to read, because you do not explicitly know what is being passed in.

然而,我觉得鼓励强类型输入,但是松散耦合是不好的.

Yet I feel like strongly typed is encouraged, but loosely coupling is bad.

我觉得我对松散耦合的解释不正确,或者其他人读错了方式. 当一个类引用另一个类的具体实例时,与我的强烈耦合.松耦合是当一个类引用另一个类可以实现的接口时.

I feel either my interpretation of loose coupling is off or others are reading it the wrong way. Strong coupling to me is when a class references a concrete instance of another class. Loose coupling is when a class references an interface that another class can implement.

那么我的问题是为什么不专门调用类的具体实例/定义?我将其模拟为专门定义所需的变量类型. 我一直在阅读有关依赖注入"的内容,他们似乎认为松散耦合可以提供更好的设计.

My question then is why not specifically call a concrete instance/definition of a class? I analogize that to specifically defining the variable type you need. I've been doing some reading on Dependency Injection, and they seem to make it out as fact that loose coupling better design.

推荐答案

首先,您正在将苹果与橙子进行比较,所以让我尝试从两个角度进行解释.键入是指如何执行对值/变量的操作以及是否允许对它们进行操作.与内聚相反,耦合是指一个(或几个)软件的体系结构.两者根本不直接相关.

First of all, you're comparing apples to oranges, so let me try to explain this from two perspectives. Typing refers to how operations on values/variables are performed and if they are allowed. Coupling, as opposed to cohesion, refers to the architecture of a piece (or several pieces) of software. The two aren't directly related at all.

强类型化的语言(通常)是一件好事,因为行为定义明确.举两个来自维基百科的例子:

A strongly typed language is (usually) a good thing because behavior is well defined. Take these two examples, from Wikipedia:

键入错误:

a = 2
b = '2'

concatenate(a, b) # Returns '22'
add(a, b)         # Returns 4

上面的内容可能会造成一些混乱,并且定义不明确,因为某些语言可能会将ASCII(可能是十六进制,可能是八进制等)数字值用于加法或串联操作,因此存在很大的出错空间.另外,很难看到a最初是integer还是string(这可能很重要,但是该语言并不在乎).

The above can be slightly confusing and not-so-well-defined because some languages may use the ASCII (maybe hex, maybe octal, etc) numerical values for addition or concatenation, so there's a lot of room open for mistakes. Also, it's hard to see if a is originally an integer or a string (this may be important, but the language doesn't really care).

强键入:

a = 2
b = '2'

#concatenate(a, b)     # Type Error
#add(a, b)             # Type Error
concatenate(str(a), b) # Returns '22'
add(a, int(b))         # Returns 4

正如您在此处看到的那样,所有内容都更加明确,您知道什么是变量,以及何时更改任何变量的类型.

As you can see here, everything is more explicit, you know what variables are and also when you're changing the types of any variables.

维基百科说:

弱打字的优势 是它需要更少的精力 比程序员的一部分,因为 编译器或解释器隐式 执行某些类型的转换. 但是,一个声称的缺点是 弱类型的编程系统 在编译时捕获更少的错误,并且 其中一些可能在之后仍然存在 测试已经完成.二 支持的常用语言 许多隐式转换是 C和C ++,有时有人声称 这些是弱类型语言. 但是,其他人则认为这些 语言对 不同类型的操作数如何 混合,应该考虑两者 作为强类型语言.

The advantage claimed of weak typing is that it requires less effort on the part of the programmer than, because the compiler or interpreter implicitly performs certain kinds of conversions. However, one claimed disadvantage is that weakly typed programming systems catch fewer errors at compile time and some of these might still remain after testing has been completed. Two commonly used languages that support many kinds of implicit conversion are C and C++, and it is sometimes claimed that these are weakly typed languages. However, others argue that these languages place enough restrictions on how operands of different types can be mixed, that the two should be regarded as strongly typed languages.

强类型打字和弱类型打字都有其优点和缺点,两者都不是好事.了解差异和相似点很重要.

Strong vs weak typing both have their advantages and disadvantages and neither is good or bad. It's important to understand the differences and similarities.

直接来自维基百科:

在计算机科学中,耦合或 依赖是每个人的程度 程序模块依赖于以下每个 其他模块.

In computer science, coupling or dependency is the degree to which each program module relies on each one of the other modules.

通常将耦合与 凝聚.经常低耦合 与高凝聚力相关,并且 反之亦然.软件质量 耦合和内聚的度量是 由拉里·康斯坦丁(Larry Constantine)发明, 结构化的原始开发者 设计者也是早期的拥护者 这些概念(另请参阅SSADM). 低耦合通常是一个迹象 结构良好的计算机系统和 好的设计,当与 高凝聚力,支持一般 高可读性的目标 可维护性.

Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. The software quality metrics of coupling and cohesion were invented by Larry Constantine, an original developer of Structured Design who was also an early proponent of these concepts (see also SSADM). Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability.

简而言之,低耦合是非常紧密,可读和可维护的代码的标志.当处理海量的API或大型项目(其中不同部分相互作用形成一个整体)时,首选高耦合. 好与坏.一些项目应该紧密耦合,即嵌入式操作系统.其他应该松散耦合,即网站CMS.

In short, low coupling is a sign of very tight, readable and maintainable code. High coupling is preferred when dealing with massive APIs or large projects where different parts interact to form a whole. Neither is good or bad. Some projects should be tightly coupled, i.e. an embedded operating system. Others should be loosely coupled, i.e. a website CMS.

希望我在这里有所启发:)

Hopefully I've shed some light here :)

这篇关于为什么紧密耦合不好但强类型好?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆