正确的编程姿势

2019-10-08 15:35 来源:未知

那些类型在付出之处已经违反了自家的一对感到到,对于程序设计的感到到。从自己对数据库和服务器的连年经验,使用基于数据表和数目表明的架空结构,你总能获得最简便易用可扩张的软件结构。

然并卵!

相当多语言都有 union 的变体,当代语言中的泛型正是 union 的一种语法糖,不过你频仍忘记了这种协会的着实价值和谋算。留神回味下那一个全新的宏图:

当项目变得很变得庞大的时候,作者意识到设计方式屁都不是。诸如桥接、装饰器以及其他,都是创建在一种纵然,要是你的父组件和子组件总是能够忽略对方的细节,而可以统一的处理它们。比方,面包有奶油味、抹茶味、水果味,面包又有最少材质、高端质感,那么您可以把味道和素材分为多个差别的接口,然后分别抽象,何况结合那三个接口生成更足够的面包,比如低等材质的抹茶味面包。然则,真实的编制程序世界中,这样的可以图景比非常少。在真实的编制程序世界中,面包还想要越来越多的东西,例如奶油味的有糖,抹茶味的从未有过糖,有糖的面包放在左侧柜台上,未有糖的面包放在左侧柜台上。看见了啊,复杂度进级了,柜台跟面包有未有糖是绑定的。那象征,倘诺您想像前边那么抽象四个接口---味道和质地,那你今后必需思量柜台。因为低等材料的抹茶味面包是从未有过糖的,放在左边柜台。今后,你不得不抽象出味道和柜台的关联。在地方的接口之上再追加一层。每当你的急需复杂一点,这种层就能够进级。比方,白砂糖面包和白砂糖面包。

总之,尽管设计情势制止了类承继的爆炸,但是也幸免不了抽象层级的盘根错节。

然则,这几个绘图项目实在很复杂,涉及了多数的多态和关系。举个例子,在五个长的列表中蕴藏种类不一的图纸,这个图片存款和储蓄的绘图数据和相关音信都不如,笔者索要把那些数据视做同一种类型,然后迭代它们,选出须求的贰个同期采纳它的有关信息。所以,笔者尝试运用学术界的设计形式来缓慢解决之中的难题。

接下来,使用一个链表恐怕数组,把那些 union 装进去,遍历,cast,然后使用你须求的特定数据。

不错,我们必要的便是多少的抽象和数据的解释器。用表来存款和储蓄你须要的次第数据,对于多态,C 语言中轻易直接干净:union。使用那样三个总结的布局,你能积攒各类差异的品类,况兼你只要求仓库储存他们的指针,那意味着你不会浪费多少内部存款和储蓄器,同不常候你能博取同等内部存储器段不过多少差异的画饼充饥。

原稿链接
A few years ago I saw this page: http://www.csis.pace.edu/~bergin/patterns/ppoop.html

Local discussion focused on figuring out whether this was a joke or not. For a while, we felt it had to be even though we knew it wasn't. Today I'm willing to admit the authors believe what is written there. They are sincere.

But... I'd call myself a hacker, at least in their terminology, yet my solution isn't there. Just search a small table! No objects required. Trivial design, easy to extend, and cleaner than anything they present. Their "hacker solution" is clumsy and verbose. Everything else on this page seems either crazy or willfully obtuse. The lesson drawn at the end feels like misguided epistemology, not technological insight.

It has become clear that OO zealots are afraid of data. They prefer statements or constructors to initialized tables. They won't write table-driven tests. Why is this? What mindset makes a multilevel type hierarchy with layered abstractions better than searching a three-line table? I once heard someone say he felt his job was to remove all while loops from everyone's code, replacing them with object stuff. Wat?

But there's good news. The era of hierarchy-driven, keyword-heavy, colored-ribbons-in-your-textook orthodoxy seems past its peak. More people are talking about composition being a better design principle than inheritance. And there are even some willing to point at the naked emperor; see http://prog21.dadgum.com/156.html for example. There are others. Or perhaps it's just that the old guard is reasserting itself.

Object-oriented programming, whose essence is nothing more than programming using data with associated behaviors, is a powerful idea. It truly is. But it's not always the best idea. And it is not well served by the epistemology heaped upon it.

Sometimes data is just data and functions are just functions.

--- Rob Pike (One of the Unix creators (Ken Thompson, Dennis M. Ritche, and Rob Pike))

几年前作者看来了那一个网页: http://www.csis.pace.edu/~bergin/patterns/ppoop.html

本人的确不亮堂那篇小聊到底是还是不是在好笑。读了一下,作者即使很想说那不是一篇好笑的篇章,不过,拜托,它根本就是。让自家来跟你们讲讲他们在好笑什么吧。

e...依据他们的言语,笔者应该称自个儿为 hacker(红客),不管作者不关注这几个。Hello! 你只必要二个小的无法再小的 table ! 根本不必要怎么样目标。朴素平凡,轻松增添,轻松清除,(比起他们的这种设计)多 TM 轻便。他们的 “黑客 solution” 真的是又蠢又笨。他们写出来的那堆东西处处透漏着疯狂和鸠拙。他们贫乏本事认识。

很显明,OO 的狂欢者们郁郁寡欢数据。他们喜欢用讲话可能组织器来初步化 tables 。他们一贯不写 table-driven 的测验。Why is this? 得有多大的心才会选取用一类别况兼多层的类华而不实,而不去用二个小小三行 table ? 笔者早就听他们说有人用各样 OO 的事物替换掉 while 循环。

可是好新闻是,hierarchy-driven, keyword-heavy, colored-ribbons-in-your-textook orthodoxy 这么些东东快到头了。愈来愈多的人挑选组合并非持续。某个人曾经再一次起始认知OO。

面向对象编程语言,其本意是运用数据和相关的一言一动打开编制程序,那是三个很好的主见。事实确实那样。不过,这么些主张并不总是最佳的 idea。 那么些主见并不曾完全的体味编制程序的世界。

Sometimes data is just data and functions are just functions.

--- 罗布 Pike (Unix 创立者之一的 (Ken 汤普森, Dennis M. Ritche, and 罗布 Pike))

git的统一准备其实拾叁分的简要,它的数据结构很牢固,而且有加上的文书档案描述。事实上,小编十二分的扶助应该围绕大家的数据结构来安顿代码,并不是遵照其余的,作者感到这也是git之所以成功的缘由之一。[...] 依作者的视角,好程序猿和烂技师之间的差异就在于他们认为是代码更要紧依然数据结构更要紧。

在特大的品种中,大家对不是友善开拓的模块并不打听,能相当的慢明白别的模块中等高校函授数的贴切含义技艺巩固支付作用。而C++引进的各个抽象则使代码非常注重上下文,想明白一段代码,要求看多得多的上下文。

面向对象语言以目的为大旨,加一些相关联的章程,大约是呓语。重要的事物应该是数据结构,对象自作者有甚主要?真正有趣的,是在分化档案的次序的两样对象交互何况有锁法规的时候。不过,即便是此时,封装什么“对象接口”也断然大错特错,因为不再是十足对象的主题素材了。

本人本来搜到了一大堆 Linus 排斥面向对象和 C++ Java 的言辞,从感到上,这么些正是自己面对设计困难时候的感到。小编早就无多次那样化解本人的次序设计。

故而,作者感到本人又不会编制程序了。于是,小编尽量的再一次思索那几个规划,何况重新在互联网上搜寻曾经协助自个儿的宏图论调:面向数据结构编制程序并非指标。即使不是为了那个绘图项目,笔者相对不会孤注一掷再二回采用设计情势和面向对象。

enum ShapeKind {
  skLINE, skPORT, skBOARD
}

class Shape {
  kind: ShapeKind   
  value: Line | Port | Board
  contains(x: number, y: number): boolean
}

class ShapeContainer {
  shapes: Array<Shape>
  search(x: number, y: number): [ShapeKind, Shape]
}

type
  ShapeKind = enum
    skLINE, skPORT, skBOARD

  Shape = ref object
    case kind: ShapeKind
    of skLINE:
      line: Line
    of skPORT:
      port: Port
    of skBOARD:
      board: Board
    contains: (x: number, y: number): bool

  ShapeContainer = object
    shapes: seq[Shape]

proc search(c: ShapeContainer, x: number, y: number): tuple[kind: ShapeKind, shape: Shape]

近年八个礼拜,小编使用 plantuml (Bell实验室产品了贰个特级绘图工具 graphviz, 那是二个包装版)把作者的绘图项目做了壹遍周详的接口和类的可视化。使用了数不胜数设计格局,富含:桥接、装饰器、生成器、抽象工厂。绘制完后,图疑似极美丽的,接口之间的并行和参数定义清晰优雅。很赏心悦目!

有意思的是,这里有一篇其他一人长辈的很早的文字,推在 Google+ 上,来自 Unix 宗旨创立者之一 罗布 Pike:

TAG标签:
版权声明:本文由澳门国际银河备用网址发布于www.308877.com,转载请注明出处:正确的编程姿势