正确的编程姿势

近年少于独周末,我利用 plantuml (贝尔实验室产品了一个最佳绘图工具
graphviz,
这是一个包装版)把自身的绘图项目开了一致不成到的接口及类似的可视化。使用了森设计模式,包括:桥接、装饰器、生成器、抽象工厂。绘制了后,图像是蛮得意的,接口之间的并行与参数定义清晰优雅。很理想!

然并卵!

以此类别以开的处曾经背离了自身之有觉,对于程序设计之感到。从自己本着数据库暨服务器的连年涉,使用基于数据表和数目说明的纸上谈兵结构,你说到底能够赢得最简便易行容易用而扩大的软件结构。

不过,这个绘图项目实在非常复杂,涉及了成百上千的多态和涉。比如,在一个加上之列表中储存种类不一之图形,这些图片存储的绘图数据与血脉相通消息还不比,我用把这些多少视做同一栽类型,然后迭代它们,选出需要之一个而且动其的相干消息。所以,我尝试下学术界的设计模式来缓解其中的题目。

当型转移得不行庞大之时候,我发觉及设计模式屁都不是。诸如桥接、装饰器以及其他,都是立以同种植而,假而你的父组件和子组件总是好忽略对方的底细,而可合之拍卖它们。比如,面包来奶油味、抹茶味、水果味,面包又发出起码材料、高档材料,那么你可拿味道与材料分为两只例外的接口,然后分别抽象,并且做这片独接口生成更增长的面包,比如低档材料的去除茶味面包。但是,真实的编程世界被,这样的优异状态很少。在真正的编程世界面临,面包还眷恋要又多的事物,比如奶油味的起甜味,抹茶味的远非糖,有甜味的面包放在左边柜台上,没有糖的面包放在右边柜台及。看到了吧,复杂度升级了,柜台及面包来没出糖是绑定的。这象征,如果你想像前那么抽象两只接口—味道和素材,那若本必考虑柜台。因为低档材料的勾茶味面包是从来不糖的,放在右边柜台。现在,你只能抽象出味道跟柜台的涉。在面的接口之上再增一重合。每当你的要求复杂一点,这种层即会见升级。比如,红糖面包与白糖面包。

总而言之,就算设计模式避免了近似继承的爆裂,但是呢避免不了抽象层级的复杂。

故而,我道我还要休见面编程了。于是,我竭尽的双重考虑这些计划,并且又当网及搜索曾经支持我之计划论调:面向数据结构编程而不是目标。如果非是为着这绘图项目,我绝对不会见铤而走险再同赖用设计模式和面向对象。

本身当搜到了一如既往死堆 Linus 排斥面向对象和 C++ Java
的口舌,从感觉上,这些虽是自面临设计困难时候的感觉到。我都无数破这样解决自己之次序设计。

git的计划性其实非常的粗略,它的数据结构很平静,并且有长的文档描述。事实上,我特别之赞同应该围绕我们的数据结构来设计代码,而不是依据其它的,我以为就也是git之所以成功之原故有。[…]
依我之见地,好程序员和烂程序员之间的区别就在他们当是代码更重要或者数据结构更要紧。

当庞大之色面临,人们对不是友善付出之模块并无了解,能很快掌握外模块中函数的适当含义才会提高开支效率。而C++引入的各种抽象则要代码非常靠上下文,想知道一段落代码,需要看大抵得多之上下文。

面向对象语言为目标啊主干,加有并行关联的章程,简直是呓语。重要之事物应该是数据结构,对象自我来吗要?真正有意思的,是于不同类别的两样目标交互而且发生锁规则之时段。但是,即使是此时,封装什么“对象接口”也断大错特错,因为不再是纯净对象的题目了。

幽默的凡,这里有同首另外一各项长辈的可怜早的文,推在 Google+ 上,来自 Unix
核心创建者之一 Rob Pike:

初稿链接
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 简单。他们之 “hacker 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.

— Rob Pike (Unix 创建者之一的 (Ken Thompson, Dennis M. Ritche, and
Rob Pike))

对,我们得的便是数的抽象和数目的解释器。用表来存储你得之顺序数据,对于多态,C
语言中简单直接干净:union。使用这样一个简单易行的结构,你能积存各种不同之种,而且你只是待仓储他们的指针,这代表你切莫会见浪费多少内存,同时您能够获取同内存段但是数量不同之纸上谈兵。

下一场,使用一个链表或者数组,把这个 union
装进去,遍历,cast,然后下你得的一定数据。

重重言语都发生 union 的变体,现代语言中之泛型就是 union
的均等栽语法糖,但是若往往忘记了这种结构的实在价值与作用。仔细回味下这全新的筹划:

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]