消除复杂性：基于函数编程和关系数据模型的方法

8 浏览量更新于2024-07-14 收藏 401KB PDF 举报

"Out of the Tar Pit (2006)" 是一篇由 Ben Moseley 和 Peter Marks 合著的计算机科学论文，主要讨论了软件开发中的复杂性问题，并提出了一种基于函数式编程和关系数据模型的解决方案。在这篇论文中，作者们首先指出复杂性是大型软件系统成功开发的主要障碍。他们引用了 Brooks 的观点，区分了偶然复杂性和本质复杂性。然而，他们并不完全同意 Brooks 认为当代系统中大多数复杂性是本质性的观点。Moseley 和 Marks 认为许多系统的复杂性其实源于偶然因素，即可以避免和消除的复杂性。他们识别出导致复杂性的常见原因，主要包括对状态的处理以及在分析和推理系统行为时由此带来的负担。在软件工程中，状态管理通常涉及变量的变化和数据的持久化，这往往使得系统变得难以理解和维护。作者强调，减少这种偶然复杂性对于改善软件的可维护性和可扩展性至关重要。为了更具体地说明如何解决这个问题，Moseley 和 Marks 提出了一种潜在的复杂性最小化方法，该方法基于函数式编程范式和 Codd 的关系数据模型。函数式编程鼓励无副作用的计算，它强调不可变性，这有助于降低系统的复杂性，因为状态的变化被限制在明确的边界内。而 Codd 的关系数据模型则提供了一种结构化的数据存储和访问方式，通过使用SQL查询语言，可以简化数据操作并减少状态处理的复杂性。在论文的介绍部分，作者提到了自1968年首次提出“软件危机”以来，问题的严重性实际上有所加剧。他们认为，应对大型软件系统的复杂性是当前亟待解决的关键问题。通过采用函数式编程和关系数据模型，他们希望为解决这一问题提供一个新的视角和实用的方法，以实现软件开发的高效和可持续。 "Out of the Tar Pit" 论文探讨了软件开发中的复杂性问题，特别是由状态处理引起的复杂性，并提出了一个以函数式编程和关系数据模型为基础的策略，旨在最小化软件系统的复杂性，从而提高其质量和可维护性。这篇论文对于理解软件设计原则和优化开发流程具有重要的参考价值。

We also want to draw attention to one of Dijkstra’s [Dij72, EWD340]

thoughts on this subject:

“It has been suggested that there is some kind of law of nature

telling us that the amount of intellectual eﬀort needed grows

with the square of program length. But, thank goodness, no one

has been able to prove this law. And this is because it need not

be true. . . . I tend to the assumption — up till now not disproved

by experience — that by suitable application of our powers of

abstraction, the intellectual eﬀort needed to conceive or to un-

derstand a program need not grow more than proportional to

program length.”

We agree with this — it is the reason for our “in most current systems”

caveat above. We believe that — with the eﬀective management of the

two major complexity causes which we have discussed, state and control —

it becomes far less clear that complexity increases with code volume in a

non-linear way.

4.4 Other causes of complexity

Finally there are other causes, for example: duplicated code, code which

is never actually used (“dead code”), unnecessary abstraction

, missed

abstraction, poor modularity, poor documentation. . .

All of these other causes come down to the following three (inter-related)

principles:

Complexity breeds complexity There are a whole set of secondary causes

of complexity. This covers all complexity introduced as a result of not

being able to clearly understand a system. Duplication is a prime ex-

ample of this — if (due to state, control or code volume) it is not clear

that functionality already exists, or it is too complex to understand

whether what exists does exactly what is required, there will be a

strong tendency to duplicate. This is particularly true in the presence

of time pressures.

Simplicity is Hard This was noted above — signiﬁcant eﬀort can be re-

quired to achieve simplicity. The ﬁrst solution is often not the most

simple, particularly if there is e xisting complexity, or time pressure.

Simplicity can only be attained if it is recognised, sought and prized.

Particularly unnecessary data abstraction. We examine an argument that this is

actually most data abstraction in section 9.2.4.

Power corrupts What we mean by this is that, in the absence of language-

enforced guarantees (i.e. restrictions on the power of the language)

mistakes (and abuses) will happen. This is the reason that garbage

collection is good — the power of manual memory management is

removed. Exactly the same principle applies to state — another kind

of power. In this case it means that we need to be very wary of any

language that even permits state, regardless of how much it discourages

its use (obvious examples are ML and Scheme). The bottom line is

that the more powerful a language (i.e. the more that is possible within

the language), the harder it is to understand sys tems constructed in

it.

Some of these causes are of a human-nature, others due to environmental

issues, but all can — we believe — be greatly alleviated by focusing on

eﬀective management of the complexity causes discussed in sections 4.1–4.3.

5 Classical approaches to managing complexity

The diﬀerent classical approaches to managing complexity can perhaps best

be understood by lo oking at how programming languages of each of the three

major styles (imperative, functional, logic) approach the issue. (We take

object-oriented languages as a commonly used example of the imperative

style).

5.1 Object-Orientation

Object-orientation — whilst being a very broadly applied term (encom-

passing everything from Java-style class-based to Self-style prototype-based

languages, from single-dispatch to CLOS-style multiple dispatch languages,

and from traditional passive objects to the active / actor styles) — is essen-

tially an imperative approach to programming. It has evolved as the domi-

nant method of general software development for traditional (von-Neumann)

computers, and many of its characteristics spring from a desire to facilitate

von-Neumann style (i.e. state-based) computation.

5.1.1 State

In most forms of object-oriented programming (OOP) an object is seen as

consisting of some state together with a set of procedures for accessing and

manipulating that state.

This is essentially similar to the (earlier) idea of an abstract data type

(ADT) and is one of the primary strengths of the OOP approach when

compared with less structured imperative styles. In the OOP context this

is referred to as the idea of encapsulation, and it allows the programmer to

enforce integrity constraints over an objec t’s state by regulating access to

that state through the acce ss procedures (“methods”).

One problem w ith this is that, if several of the access procedures ac-

cess or manipulate the same bit of state, then there may be several places

where a given constraint must be enforced (these diﬀerent access procedures

may or may not be within the same ﬁle depending on the speciﬁc language

and whether features, such as inheritance, are in use). Another major prob-

lem

is that encapsulation-based integrity constraint enforcement is strongly

biased toward single-object constraints and it is awkward to enforce more

complicated constraints involving multiple objects with this approach (for

one thing it becomes unclear where such multiple-object constraints should

reside).

Identity and State

There is one other intrinsic aspect of OOP which is intimately bound up

with the iss ue of state , and that is the concept of object identity.

In OOP, each object is seen as being a uniquely identiﬁable entity re-

gardless of its attributes. This is known as intensional identity (in contrast

with extensional identity in which things are considered the same if their

attributes are the s ame). As Baker observed [Bak93]:

In a sense, object identity can be considered to be a rejection of

the “relational algebra” view of the world in which two objects

can only be distinguished through diﬀering attributes.

Object identity does make sense when objects are used to provide a

(mutable) stateful abstraction — because two distinct stateful objects can

be mutated to contain diﬀerent state even if their attributes (the contained

state) happen initially to be the same.

However, in other situations where mutability is not required (such as —

say — the need to represent a simple numeric value), the OOP approach is

forced to adopt techniques such as the creation of “Value Objects”, and an

this particular problem doesn’t really apply to object-oriented languages (such as

CLOS) which are based upon generic functions — but they don’t have the same concept

of encapsulation.

剩余65页未读，继续阅读

weixin_38625708

粉丝: 4
资源: 945

消除复杂性：基于函数编程和关系数据模型的方法

Out of the Tar Pit - 2006 (MoseleyMarks06a)-计算机科学

td-pit与td-pite的区别

> pit-cloud-front@0.0.1 dev > vue-cli-service serve 'vue-cli-service' 不是内部或外部命令，也不是可运行的程序 或批处理文件怎么解决这个问题

The signal f(t)=10sin(4pit)+sin(48pit)+5sin(89pit) is sampled at the frequency of 5HZ. What frequencies are there in the output ?

生成个java文字游戏代码

peach pit协议文件

MK22FN512VLH12单片机使用官方库设置定时器0为100us中断

应用matlab对信号x(t) = 3 + 2 * cos(pit-pi/2) + cos(2pit + pi/3) + 0.5 cos(4pi*t + pi/6)进行频谱分析

最新资源

> pit-cloud-front@0.0.1 dev > vue-cli-service serve 'vue-cli-service' 不是内部或外部命令，也不是可运行的程序或批处理文件怎么解决这个问题