it-e-48 OOP Is Much Better in Theory Than in Practice

Like many ideas that sound good in theory but are clumsy in practice, object-oriented
programming (OOP) offers benefits only in a specialized context—namely, group programming.
And even in that circumstance the benefits are dubious, though the proponents of OOP would
have you believe otherwise. Some shops claim OOP success, but many I've spoken with are still
"working on it." Still trying to get OOP right after ten years? Something strange is going on here.
Certainly for the great majority of programmers—amateurs working alone to create
programs such as a quick sales tax utility for a small business or a geography quiz for
Junior—the machinery of OOP is almost always far more trouble than it's worth. OOP just
introduces an unnecessary layer of complexity to procedure-oriented design. That's why very few
programming books I've read use OOP techniques (classes, etc.) in their code examples. The
examples are written as functions, not as methods within objects. Programming books are trying
to teach programming—not the primarily clerical and taxonomic essence of OOP. Those few
books that do superimpose the OOP mechanisms on their code are, not surprisingly, teaching
about the mysteries of OOP itself.
Of course professional gang programming has specialized requirements. Chief among them
is that the programmers don't step on each other's toes. For instance, a friend who programs for
one of the world's largest software companies told me he knows precisely what he'll be working
on in one year. Obviously, OOP makes sense in such a bureaucratic system because it needs to be
intensely clerical. Helping to manage large-scale, complex-programming jobs like the one in
which my friend is involved is the primary value of OOP. It's a clerical system with some built-in
security features. In my view, confusing OOP with programming is a mistake.
Contradiction Leads to Confusion
Consider the profound contradiction between the OOP practices of encapsulation and
inheritance. To keep your code bug-free, encapsulation hides procedures (and sometimes even
data) from other programmers and doesn't allow them to edit it. Inheritance then asks these same
programmers to inherit, modify, and reuse this code that they cannot see—they see what goes in
and what comes out, but they must remain ignorant of what's going on inside. In effect, a
programmer with no knowledge of the specific inner workings of your encapsulated class is
asked to reuse it and modify its members. True, OOP includes features to help deal with this
problem, but why does OOP generate problems it must then deal with later?
All this leads to the familiar granularity paradox in OOP: should you create only extremely
small and simple classes for stability (some computer science professors say yes), or should you
make them large and abstract for flexibility (other professors say yes). Which is it?
A frequent argument for OOP is it helps with code reusability, but one can reuse code
without OOP—often by simply copying and pasting. There's no need to superimpose some
elaborate structure of interacting, instantiated objects, with all the messaging and fragility that it

introduces into a program. Further, most programming is done by individuals. Hiding code from
oneself just seems weird. Obviously, some kind of structure must be imposed on people
programming together in groups, but is OOP—with all its baggage and inefficiency—the right

1, dubious  ['dju:bjəs]
a. 怀疑的,可疑的

2, proponents  
n. 支持者;建议者(proponent的复数)

3, quiz  [kwiz]
n. 小考,随堂测验,恶作剧
v. 简单测验,恶作剧

4, clerical  ['klerikəl]
n. 牧师
a. 书记的,事务上的,抄写员的

5, essence  ['esns]
n. 本质,精髓

6, bureaucratic  [,bjurəu'krætik]
adj. 官僚的;官僚政治的

7, intensely  
ad. 强烈地(一心一意地)

Continue reading it-e-48 OOP Is Much Better in Theory Than in Practice

link css 加载判断,解决不了的问题?


Chrome / Safari:
    linkNode.sheet 在 css 文件下载完成并解析好后才有值,之前为 undefined
    linkNode.sheet.cssRules 同域时返回 CSSRuleList, 跨域时返回 null


    linkNode.sheet 在 css 插入 DOM 中后立刻有值,插入前为 undefined
    linkNode.sheet.cssRules 在文件还未下好时,抛出 NS_ERROR_DOM_INVALID_ACCESS_ERR
                              同域时返回 cssRuleList
                             只要是跨域(不管对错)抛出 NS_ERROR_DOM_SECURITY_ERR

  IE6-9 / Opera:
    linkNode.sheet 和 cssRules 在 css 插入 DOM 后都立刻可访问,cssRules 为 []
    当文件下载完成时,cssRules 为 cssRuleList
    IE 下,无论成功失败,都会触发 onload
    Opera 只在成功时才触发 onload,跨域时访问cssRules 会抛异常。

  缺陷:Opera 遇到 404 时,需要降级到 timeout


name="code" class="js:firstline[1]">function checkcss(link) { try { if (link.sheet && link.sheet.cssRules.length > 0) return true; else if (link.styleSheet && link.styleSheet.cssText.length > 0) return true; else if (link.innerHTML && link.innerHTML.length > 0) return true; }

Continue reading link css 加载判断,解决不了的问题?



public static String buildUrl(String strHost, String strContext, String argAbsolutePath)
		if (!argAbsolutePath.startsWith("/"))
			argAbsolutePath = "/" + argAbsolutePath;
		return MessageFormat.format("http://{0}{1}{2}", new Object[] { strHost, strContext, argAbsolutePath });



使用的是apache,发现可以通过设置ProxyPreserveHost 为On来不改变原始host值。

当然即使不开ProxyPreserveHost 选项apache也会加个X-Forwarded-Host来获得原始host,不过这个头不是标准http头。



Continue reading 使用反向代理问题

it-e-47 Object Orienta tion

OO can model a complex reality in a very natural way.
An example is "the cup of coffee". This shows interaction between customer, waiter and
Customer and kitchen don't know each other. The waiter is the intermediary. (Encapsulation).
Waiter and kitchen act differently to the request "a black coffee" (Polymorphism)
Both waiter and kitchen supply coffee (Inheritance).
The benefits of OO are higher for complex business processes. The more complex the better.
Different responsibilities, lots of exceptions, and processes that "look alike". Those are the ideal
ingredients for an OO approach.

Encapsulation means as much as shielding. Each
OO object has a shield around it. Objects can't "see" each
other. They can exchange things though, as if they are
interconnected through a hatch.
Customer, waiter and kitchen are three shielded objects
in the "cup of coffee" example. Customer and kitchen do not
know each other. The waiter is the intermediary between
those two. Objects can't see each other in an Object-oriented
world. The 'hatch' enables them to communicate and exchange coffee and money.
Encapsulation keeps computer systems flexible. The business process can change easily.
The customer does not care about the coffee brew process. Even the waiter does not care. This
allows the kitchen to be reconstructed, is only the "hatch" remains the same. It is even possible to
change the entire business process. Suppose the waiter will brew coffee himself. The customer
won't notice any difference.
Encapsulation enables OO experts to build flexible systems. Systems that can extend as your
business extends. Every module of the system can change independently, no impact to the other
Objects can respond differently to the same message. Both waiter as kitchen respond to"a
black coffee".
The actions are different though.
The waiter passes the message to the
kitchen, waits for response, delivers
coffee and settles the account.
The kitchen brews fresh coffee and
passes it to the waiter.
The same message with different
implementations, that is polymorphism.
Polymorphism makes Object-oriented systems extremely suitable for various exceptions and
exceptions to exceptions.
Similar, but just a little bit different. The world is full of exceptions and similarities. Object
Orientation places everything perfectly in a class tree.
Both waiter and cook are employees. So they both
have an employee number. This generic
employee number gets a generic place in
Both return a cup of coffee to the question "A
cup of coffee please". That similar behavior

also gets a generic place in Employee.
There are some exceptions. Waiter and
Cook have different methods to get a
cup of
coffee. Those specific methods get a
specific place, reusing the more generic
part in Employee.
No matter how complex your business
situation is, Object Orientation can cope with


1, intermediary  [,intə'mi:diəri]
adj. 中间的;媒介的;中途的
n. 中间人;仲裁者;调解者;媒介物

2, hatch  [hætʃ]
n. 孵化;舱口
vt. 孵;策划
vi. 孵化

3, cope  [kəup]
v. (with)竞争,对抗,对付,妥善处理
vi. 对付,妥善处理

Continue reading it-e-47 Object Orienta tion


setCapture一般用在drag move,resize的实现上。它只能在IE上使用,目的是为了捕获onclick, ondblclick, onmousedown, onmouseup, onmousemove, onmouseout, 和onmouseover这类鼠标事件,不让目标节点失去捕获。



Continue reading setCapture这个事,move,drag

it-e-46 Object-oriented programming

Object-oriented programming (OOP) refers to a special type of programming that combines
data structures with functions to create re-usable objects.
Otherwise, the term object-oriented is generally used to describe a system that deals primarily
with different types of objects, and where you can take the actions depends on what type of object
you are manipulating. For example, an object-oriented draw program might enable you to draw
many types of objects, such as circles, rectangles, triangles, etc. Applying the same action to each of
these objects, however, would produce different results. If the action is Make 3D, for instance, the
result would be a sphere, box, and pyramid, respectively.
Many languages support object oriented programming. In OOP data and functions are
grouped together in objects (encapsulation). An object is a particular instance of a class. [1] Each
object can contain different data, but all objects belonging to a class have the same functions
(called methods). So you could have a program with many e-mail objects, containing different
messages, but they would all have the same functionality, fixed by the email class. Objects often
restrict access to the data (data hiding).
Classes are a lot like types the exact relationship between types and classes can be complicated
and varies from language to language.
Via inheritance, hierarchies of objects can share and modify particular functions. You may
have code in one class that describes the features all e-mails have (a sender and a date, for
example) and then, in a sub-class for email containing pictures, add functions that display images.
[2]Often in the program you will refer to an e-mail object as if it was the parent (super-class)
because it will not matter whether the e-mail contains a picture, or sound, or just text. This code
will not need to be altered when you add another sub-class of e-mail objects, containing (say)
electronic cash.
Sometimes you may want an action on a super-class to produce a result that depends on
what sub-class it "really is". For example, you may want to display a list of email objects and
want each sub-class (text, image, etc) to display in a different colour. In many languages it is
possible for the super-class to have functions that sub-classes change to suit their own purposes
(polymorphism, implemented by the compiler using a technique called dynamic binding). So
each email sub-class may supply an alternative to the default, printing function, with its own
In many OO languages it is possible to find out what class an object is (run time type
information) and even what functions are connected with it (introspection / reflection). Others,
like C++ have little run time information available (at least in the standard language individual
libraries of objects can support RTTI with their own conventions).
[3]There are at least three approaches to OO languages: Methods in Classes, Multi-Methods
Separate from Classes, Prototypes.

Many languages follow Smalltalk in associating functions (methods) with classes. The
methods form part of a class definition and the language implementation will have (this is a
low-level detail hidden from the programmer) a vtable for each class which links methods to their
implementations. This indirection is necessary to allow polymorphism, but introduces a
performance penalty. In some languages (C++, at least), only some methods, marked as virtual
by the programmer, are treated in this way.

Some languages (e.g. common Lisp / CLOS) allow functions to specialise on the class of
any variable that they are passed (multi-methods). Functions cannot be associated with one class
because different versions of the function may exist for many different combinations of classes.

Other OO languages do away with classes completely (e.g. Self). Prototype-based languages
create new objects using an existing object as an example (prototype). Apart from solving some
problems with dynamic object creation, this approach also encourages delegation (function calls
are passed to other objects) rather than inheritance.


Continue reading it-e-46 Object-oriented programming


iOS平台目前主要泛指iPod Touch、iPhone以及iPad这三种主要的机型,近日开始研读起iOS Human Interface Guide(后简称HIG)的相关章节,发现其实有许多一般入门时常见的问题,其实都可以在这里获得解答。兹就经验上许多人可能会产生的疑问,并配合上述 HIG文件内容进行一份整理。 如同「平台特性(Platform Characteristics)」章节开头所明述的,成功的应用程序将会拥抱这些特性,并融合在让用户在操作装置之间,所以熟知iOS上的平台特性,合理的设计以及运用其在自己所开发的应用程序中,将会对于用户在操作应用程序时,有大大的帮助。
◆最舒适的点击区域大小是 44 x 44 点 (Points而非Pixels)

基本上,原则就是Home Screen如何,进入应用程序的默认显示方向就会是如何。
◆由于iPhone以及iPod Touch的主画面(Home Screen),只会有一种显示方向,所以默认进入到应用程序时,就应该会是直立向。



对,这听起来的确是很废话,在使用者的面前,只会有一个应用程序在前台与用户互动。在iOS 4之前,应用程序被关掉之后,就会被从内存中移除;但iOS 4之后,他可能会在背景继续执行,这个一般称之为多任务(Multitasking),应用程序通常会在背景执行直到他们下次被呼叫出来,或者直接被终止工作才会停止运作。
在主画面中,快速按Home Screen圆钮两次,就可以叫出位于画面最底端的多任务选单,使用者可以快速的找到最近用过的应用程序。当用户再一次使用这些应用程序的时候,这些程序就不用再重新被加载,而是会被从他们上次跳出的地方进入。
iOS应用程序是利用iOS SDK开发的应用程序,也可以称之为原生应用程序(Native App),由于这些iOS应用程序重组了内建应用程序的特色,所以依附在装置上之时,就可以在iOS环境下有特别的优势。人们会把这些应用程序当作像内建的相簿、行事历以及信箱。
◆网站应用程序(Web apps),行为近似于iOS应用程序,一般的网站应用程序通常会隐藏Safari浏览器的接口,让他看起来像是原生的应用程序。
◆优化网页(Optimized webpages),网页有针对iOS上的Safari浏览器进行优化,并移除一些不被支持的效果,像是Plug-In、Flash以及Java。更甚者,还会针对屏幕大小进行内容的排版调整等,以使得在装置上可以被最佳的阅读。
◆兼容网页(Compatible webpages),这是与上者相对的,网页可以在iOS上被浏览,但是通常会遇到一些无法支持的元素,排版之类的也不见得会适合在装置上阅读,但是通常都可以被显示出来。 在iOS用来浏览网页的Safari
在iOS上的Safari不支持 Flash、Java(含Java applets)或者第3方的网站内容插件。但支持HTML 5的以及 标签以提供影音串流,以及JavaScript、CSS 3以显示动画内容。

Continue reading 【转】苹果iOS平台成功的应用程序特性大整理

IPhone In Action 读书笔记

1章介绍,2-9章web,10-20章sdk(sdk tools)

mac os基于unix发展

480*320 像素输出屏幕。

wifi→EDGE(Enhanced Data Rate for GSM Evolution,增强型数据速率GSM演进技术,最大220kbps)→3G(384kbps--1000kbps)

web开发工具 iui库) ,dashcode(IDE)


1.4.1 web视图是980px缩放的效果?


            带url   不显示url

竖向 26%      13%

横向 35%     16%




第九章初步介绍了 objectC








不能包含ip voice功能





大部分将UI操作会和Cocoa Touch打交道,但是也有要使用ObjectC类的情况,这就在Core Foundation(类名以CF开头)之上了。

Cocoa Touch包含 UIKit(类名以UI开头)和Foundation(类名以NS开头)



第十九章讲图形 Quartz 2D,openGL等

Quartz 2D建立在老的Core foundation之上??


cocos2d是封装的openGL,也用到了quartz 2D

Quartz默认的坐标系是从右下到左上,与Cocoa Touch整好相反。如果你不是使用Cocoa Touch创建context,就要认为坐标原点是右下。



19.4.5 状态管理 save,restore.--和canvas2d像吧


19.7 动画介绍

19.8 OpenGL ES(Embded System)

EAGL is Embedded AGL(Apple's OpenGL extensions for OS X.)



详细见apple文档OpenGL ES Framework Reference,里面也有示例。

Continue reading IPhone In Action 读书笔记

iphone 那些事


主要的教程在 上找,

按照他的来,不懂得再google, 越的时候比较难操作的是进入DFU模式,那真叫技术活。


下一步开始更新cydia,但没wifi 怎么办,最后发现win7下Connectify可以直接做热点,哈哈,wifi是好了,但是cydia还是说什么网络错误。我找了新的源,任然如此。没办法,就按照里面提到的离线安装模式,使用iFunBox装了ipa补丁。



Continue reading iphone 那些事


Total views.

© 2013 - 2020. All rights reserved.

Powered by Hydejack v6.6.1