过程编程时代的设计模式是什么?[关闭]


24

相似:20年前编程是如何完成的?

OOP如今非常流行,其起源于1960年代的Simula 67,后来被SmalltalkC ++所流行。我们有DRY,SOLID,以及许多有关面向对象世界中的设计模式的书籍。

但是在广泛采用OOP范式之前,编程的主要原则是什么?主要的设计模式是什么?


11
OOP实际上有点老:请参阅en.wikipedia.org/wiki/Smalltalk。另外,DRY并非OOP独有。尽管它们对如何实现它有不同的答案,但该原理可以是(应该是)所有编程范例。
tdammers 2013年

4
OOP主要来自Simula
Charles Salvia

8
OOP起源于C ++ ???这些天孩子们... :(
Andres F.

5
幸运的是,所有行销毫无用处的胡言乱语,所有炒作都是我们行业中相对较新的事物。在过去,我们只是编程,没有废话。
SK-logic

@AndresF。,请随时在我的问题中直接对其进行编辑。
Vorac

Answers:


31

在学习Java之前,我是Cobol开发人员。我已经开发超过35年了。

早在过程语言时代,大多数处理都是分批完成的。追溯到足够远的历史,甚至使用一批打孔卡完成程序编译。

与Kilian Foth的主张相反,我们的设计模式可以追溯到1970年代和1980年代。在Cobol中,有一种编码多文件匹配/合并的方法。有某种方法可以将代码添加事务添加到Cobol中的主(磁带)文件中。在Cobol中,有一种编码报告生成的方法。这就是为什么IBM的Report Writer在许多Cobol商店中从未真正受到关注。

DRY原理的早期应用。创建很多段落,以免重复。结构化编码技术是在1970年代开发的,Cobol在1985年向该语言添加了结构化单词(动词)。

通常,当我们编写新的Cobol程序时,我们复制了旧的Cobol程序并更改了名称以保护无辜者。我们几乎从未用一张空白纸或一张空白屏幕编写Cobol程序的代码。当您可以复制和粘贴整个程序时,这是一个很大的设计模式。

Cobol设计模式如此之多,以至于Cobol程序员花了数年时间才能学习所有这些模式。这就是当今Cobol程序员在很大程度上仍使用1985语法的原因之一。


2
+1。我曾经在Cobol,Pascal和在Vic-20上教我自己Basic的时候有过同样的经历。我重复使用并复制了许多东西。
JohnP 2013年

BONSOP怎么样,今天仍在使用;)
dbasnett

将“复制/粘贴/更改”称为“设计模式”(至少在我们今天使用的术语中)感觉不对,也许这更像是“编码模式”?
2013年

@Izkata:这并不是真正的编码模式,因为您避免了大多数编码。“模板模式”怎么样?您说对了,按照当今的标准,复制/粘贴/更改不是一个好的设计。那时,那是我们最好的。
吉尔伯特·勒·布朗克

1
设计模式与他对C&P Cobol所做的相同,始终以完全相同的方式编码单例代码-您甚至可以立即获得一些IDE来吐出样板。与剪切和粘贴没什么大不同。
gbjbaanb 2014年

25

在您所谈论的时代,软件中的“设计模式”并不存在,因为该概念尚未被发明出来。这不是我被人轻描淡写-的确原因。被称为可识别的名称是使设计模式成为“设计模式”的原因,而不仅仅是使您一直以一种或另一种形式使用的代码(例如,“工厂”而不是“我喜欢使用的静态类而不是各种各样的构造函数”),概念本身也不例外。

就是说,当然有些事情在实践者的工作中扮演的角色与现在的设计模式完全一样。但是听到这些消息会让您失望:那些日子里典型的“大师的把戏”对我们来说现在很无聊-例如单链接列表,由每次迭代增加的索引控制的循环,聪明的“访问器” ”的方法似乎什么也没做,只是让您在稍后改变实现细节时改变了主意。

没错,我们现在认为理所当然的东西-有时甚至是我们使用的语言的一部分-曾经是高级的概念(有时是受到嫉妒的保护),只有经验丰富的编码人员才能知道。您今天在基本编程课程中几乎学到的几乎所有琐碎的事情都经历了一个阶段,在这个阶段中,道德上等效于该年龄的从业人员的“设计模式”。软件构建可能还不是严格的工程学科,但是,如果您研究50年代和60年代的最新技术,就不能否认它自诞生以来已经取得了巨大进步。


4
设计模式只是贝克和坎宁安(Beck and Cunningham)的名字,用于形式化重复代码模式的概念。他们在1987年做到了这一点。Fowler在2002年出版了他的书,并使它们流行。
gbjbaanb

1
@gbjbaanb,我认为设计模式至少
Vorac

3
@Vorac这些不是为了软件
蚊蚋

18

以前的主要范例是结构化编程。除了UML,还有各种不同的图(流程图,数据流程图,结构图等)。开发主要是自上而下的,并且遵循功能分解的过程。基本思想之一是您的程序结构应类似于菱形:位于顶部的主模块,呈扇形扩展为高级控制模块,这些模块在较低级模块中调用例程。这些较低级的模块建立在较低级的模块上,所有这些模块(理论上)最终都集中在少数基本的I / O例程上。高层模块应该包含程序逻辑,低层模块则更多地关注数据完整性和错误处理。

在此期间引入的重要概念是信息隐藏,模块化和高内聚/低耦合。有关这些主题的一些开创性论文,请参阅Dave Parnas的作品。还可以查看拉里·康斯坦丁,汤姆·德马科和埃德·尤登的作品。


是的,那就是我25年前学到的东西
Binary Worrier

10

我想其中一个很大的概念(结构化编程本身除外)是传递一个句柄的概念-在OO中,您有一个对象,它包含状态和功能。回到OO之前,您将拥有大量独立功能,并且需要在它们之间的某个状态传递一个句柄-如果愿意,可以使用cookie。这为您提供了面向对象的原理,而实际上却没有面向对象。

您可以在旧的Win32代码中看到很多,您需要传递一个HANDLE,它是代表Windows内核中分配的某些状态的不透明类型。您可以自己传递一个指针,该指针指向您先前分配给该数据的函数的第一个参数的结构。


这很有趣。我也在寻找其他示例。例如,如何“围绕数据结构构建逻辑,而不是围绕数据结构构建逻辑”?
Vorac

2
与您现在使用的方法相同,除了方法是通过约定,暗示或文档而不是特殊语言支持与数据结构关联的自由函数。
无用的

1
就像javascript如何进行OO一样,仅使用JS,函数指针才能成为您传递的结构的一部分。没什么真正的改变,我们只是在它们上面加了一层混淆:)
gbjbaanb

5

既然没有人提到明显的东西:在程序时代,一种大的设计模式就是对象。像之前(例如,子例程)和之后(例如,Iterator)之后的许多流行设计模式一样,它变得如此流行,甚至获得了语言支持。


3

“有限状态机”可以算作一个模式,并且使用OOO之前的语言编写了FSM(例如,用于通信协议)。

同样,“中断处理程序”和TSR过去也很流行,例如在DOS上。


3

诸如“意大利面条式代码”和“单一出口点”之类的术语实际上是对那个时代的回溯。如今,我们称代码为我们不喜欢的“意大利面条式代码”,但这实际上是对与GOTO和JMP捆绑在一起(严重)的代码的引用。

(今天,我们遇到了“馄饨代码”,其中的代码就像一堆不相关,紧密包装的类,就像一盘馄饨。但是,一些面向对象的专家合理地问:“但是,OO到底不是要看起来像?”)

今天的“单一出口点”只是一个令人沮丧的重构障碍。我谈论过的许多开发人员甚至都没有听说过,并且在我解释它时都非常吃惊。但是在过去,这意味着不要突然跳出代码块而进入意大利面条式代码。跳至逻辑末尾,然后正常退出。

回溯我的记忆方式,我似乎还记得,将代码捆绑到过程中的想法是一个巨大的飞跃。您可以将过程打包为可互操作,可重用的模块的想法有点像编程的圣杯。

编辑:“自我修改代码”也是一种在原始毁灭战士上特别使用的模式。那是程序实际上将根据状态使用更快的指令覆盖其指令的地方。当我是一名在科学博物馆学习编程课程的大佬时,我的教练严厉警告我们:“不要编写自我修改的代码!”

编辑:但是,在互联网出现之前,单词传播的速度要慢得多。以前,实现算法和数据结构的想法要困难得多。今天,我一直在进行排序,甚至都不知道我在使用哪种排序。但是那时候您必须自己编写代码。我记得有一篇文章谈到编程挑战,而这些挑战过去通常要花几天的时间,而今天我们需要半小时或更短的时间才能解决。因此,真正有意义的“算法”和“数据结构”编程可能会比现在更多。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.