作者qrtt1 (有些事,有时候。。。)
看板Soft_Job
标题Re: [闲聊] 不用OOP的技巧
时间Fri Mar 6 21:15:45 2015
看了标题与内文让我沉思了很久,「不用OOP的技巧」
想着有些项目是否能称为这是「技巧」或着说是「沉沦」!?
引述自己之前回文写的话:
[请益] (写程式的)热忱?!
https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1386172787.A.9A0.html
理想上 coder 要有随着年资越长舍弃更多的坏习惯,
养成更多的好习惯。
※ 引述《F23ko (名无乚)》之铭言:
: 上面在战OOP,有人把OOP批的一文不值
: 我觉得这算是时代的眼泪吧?
: OO的出现制造了一个「断层」
: 把一些年资十年以上,而且没跟着更新技术的程式设计师给区分开了
带来断层的不是 OOP 本身。
所欠缺的是在 OOP 盛行的年代,
各家 OOP 语言的开发者对自身工作方式的「反思」
OOP 刚开始的「世界观」试着把所有东西都对应成 Class
就像现今多数的入门书籍那般,
弄了个「车」「形状」「鸟类」什麽的,
但後来发现每个人对於观察事理的「粒度」差异蛮大的
要如何将事物一般化或特别没有太多的准则,
弄得太「细致」对於 caller 理解这个「小世界」的负荷加重了些
弄得太「粗略」又难适应一些需要例外规则的情况。
不过好在,大部分的程式开发人员只需写出符合工作情况的 code 就行了
顶多在程式内多个条件判断,让它能适应某种例外状况。
那麽当例外规则越来越多时该怎麽麽呢?
诸如此类的针对实例的反思与提出解决策略,才是该补上的「断层」!
这些检讨与反思多数都被收纳在 Design Pattern、Refactoring 的书籍里
赶时间也可以直接看 Clean Code 会小本一点。
虽然书中的主要核心是绕着 OO 语言打转的,
但那可以被用在许多语言,即使有些语言没有类别,
多数的情况我们不是在处理「像 class 这种静态的样版」
而是让特定的程式片段更有意义的聚集在一起
它可以是个 fucntion (或一组 function),也可能是个 closure。
不管你用的是什麽语言,有没有 OO? 都是需要培养一些「观点」
像上述提到的「书」或「概念」都是其他人的「经验」集合,
有人替我们痛苦过,并且留下了纪录,就别浪费太多青春重蹈覆辙。
其实要完全没有 OO 有可能吗?
至少我们大部分的人没有经历过完全 Procedurl Programming 的年代
http://en.wikipedia.org/wiki/Procedural_programming
写出来的东西多少还是会有 OO 的影子存在
: 我任职过的其中两间公司的程式专案有十年以上的历史
: 一个是JSP一个PHP
: 都没用物件导向
: (虽然JAVA是物件导向的程式,但是一开始写的那个人把他当C在写,没用物件导向)
: 而且都不是小系统,一个是电子公文、表单系统,一个是博奕类系统
: 专案资料夹内的档案数破万
: 当时我的工作是维护系统
: 弄一两个月之後就能弄得很顺了
: 当然也学了一些,OO还没出现时常用的一些技巧
: 1. 变数全部都放在档案的最上面
: 变数名称通常很长,这是为了避免撞名 (因为都全域变数)
就算没有 OO 也可以把「状态」集中在「容器」内传递。
就像在写 C 的时候,把一些状态收纳在 struct 内一般
然後将这个 struct 当作参数传到为它而写的 function
即使在一个没有 OO 的语言,也能有效的管理变数的 scope
差别只是在於 behavior 是以物件为中心,
或是以 procedure 为中心去操作资料
: 2. 剪下贴上也是有技巧的
: 如果变数的命名习惯跟程式风格统一的话
: 是可能做到,把这边的功能copy到另外一个档案中又能正常运作不用改的
尽可能把 copy & paste 的内容,改用 function 集合成一个动作呗。
至少你在 copy & paste 时,只要换 function 的参数名称
: 3. 批次取代是好东西
: 有人说剪下贴上会造成「改个小地方就需要修改全部」
: 这用全域搜寻以及全域取代就可以解决掉
: 会正规表示式的话更轻松
把重复的东西用 function 取代,
如果是网页部分 jsp 其实可以
1. 使用 include
2. 自订 tablib
3. 改用样版引擎或是 sitemesh 这类的东西
: 4. 不要看程式码
: 在找什麽功能,或是要修BUG时,不要一行行的去找
: 那很浪费时间
: 要学会找程式码中的关键字,或是function、变数名称
: 用全域搜寻去把可疑的地方捞出来看
这个善用 logger 的讯息来找会再让你更快一点,
另一个适用於各语言的终极兵器应该是 debugger
诚心建议写写 unit test :)
: 以上是一些,非OO的状况下处理的方式
: 那些上个世代的程式设计师似乎挺习惯这样做
: 我要推MVC或是其他新的方式给他们,还推不动.....
我想与世代的关系不大,我知道一些比我早入行的前辈
他们依然保持着让我追不上的进化速度......Orz
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 59.115.98.31
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1425647748.A.4C0.html
1F:推 et282523: 推~ 03/06 21:25
2F:→ qrtt1: 好尴尬,写完了,发现原来的文章不见了. 03/06 21:28
3F:→ dreamnook: 原文砍了 回文辛苦了 XD 03/06 21:29
4F:推 zxc1020305: 推 03/06 21:31
5F:推 F23ko: 推这篇 03/06 21:46
6F:→ F23ko: 原本那篇连续被嘘废文,我就在想说那些现象对其他人说也不 03/06 21:49
7F:→ F23ko: 是那麽有趣的历史... 03/06 21:50
8F:→ qrtt1: @F23ko 我有接手过那种 style 的 code,在能力所择的范围 03/06 21:51
9F:→ qrtt1: 我加了 unit test 并把一些 duplicated code 抽成 utils 03/06 21:51
10F:→ qrtt1: 在新加功能、修 Bug 时才加 test case & refactoring 03/06 21:52
11F:→ qrtt1: 其他旧的部分,还不知道会不会用到就先放着了。 03/06 21:53
12F:→ F23ko: 我在两间公司都试着这样干,一间是告诉我「这样很难维护」 03/06 22:04
13F:→ F23ko: 就把我写的class拆掉,改回原本那种写法。另外一间还比较会 03/06 22:05
14F:→ F23ko: 去吸收一下新的东西。真的还是要看人.... 03/06 22:06
15F:→ F23ko: 啊对了,跟我讲「很难维护」那间公司还在用table排版 03/06 22:07
16F:→ csfgsj: 给楼上,不要怕网路上的酸酸。像哥哥早就链成金刚不坏之身 03/06 22:31
17F:→ csfgsj: 他们越骂你,收视率就越高。跟政论节目一样 03/06 22:31
18F:→ dreamnook: 并不是金刚不坏之身 只是很会跳针 03/06 22:44
19F:推 iceonly: 把一切都当成酸酸,就跟把一切乡民都当成网军一样 03/06 23:21
20F:推 typepeter: 实用 03/07 00:24
22F:推 roger00: 推 03/15 23:00