欧美日韩国产欧美日美国产精品,亚洲国产精品久久久久婷婷老年,亚洲一区二区三区在线免费

A Walk On JSR220 Persistent API...More Ugly More Cool

Frank and I collected some Hibernate tips, and we named them with some sexy names ;-) This afternoon I tried to replace hibernate by JSR220 persistent API in a typical web application, and I found some new tips in JSR220 Persisntent API (Frank, I'm here waiting your names).

btw: I'm a believer in Peter Coad's Color Modeling approach, all the following tips are modeled in the approach. I recommend you the greate book 'Java Modeling in Color with UML' if you'd no idea about the Color UML.

1. Annotating Description with @Embeddable, and the Thing it describe with @Entity

Take Product and ProductDescription for example.

@Embeddable
2

class ProductDescription {
3

private String name;
4

private String description;
5

. and getters and setters
6

}
7

@Entity(access = AccessType.FIELD)
9

class Product {
10

private ProdcutDescription description;
12

}
14

In hiberante, we could make the ProductDescription as an embedded persistent object of Product via the component tag.If the ProductDescription should be embedded in another object, we've to declare it once more.
Things become more convenient in JSR 220, because non-transite fields, whose class is annoated with @Embeddable, are treated as embedded persistent objects automatically, we'd have fine-grained persistent objects without long-winded config file.

2.Avoiding Database Field in Domain Model Using @AttributeOverride

It's claimed that Annotaton could simplify development, but considering the cost of hard-coding mapping information in source codes I prefer some other complicated ways.It's too ugly to write code like following.

@Entity(access = AccessType.FIELD)
2

@Table(name="TAB_PRODUCT")
3

class Product {
4

@Basic
6

@Column(name="NAME", nullable=false, length=512)
7

private String name;
8

}

It's sucks but could be avoided.

@EmbeddableSuperclass
2

class Product {
3

@Basic
5

private String name;
6

}
7

@Entity
9

@AttributeOverride(name="name", column=@Column(name="Name"))
10

@Table(name="TAB_PRODUCT")
11

class PersistentProduct extends Product {
12

}

We could separate the domain model and the persistent model by inheritance.Although we could do the same thing in hiberante too, we have to provide lots of configuration files.Once more we'd have hierachical persistent objects without long-winded config file.

3.Avoiding Database Primary Key in Domain Model

In most O/R mapping framework, we are always asked to give a primary key or identifier to our domain model, and we are suggested using meanless identifier instead of domain-specified identifer.It's kinda of Domain Pollution.Although we couldmake the domain model more clearer via inheritance, it's pointless for common usages.
Fortunately, we HAVE TO separate domain model and persistent model(as above mentioned), so that we can throw this bad habit away conviniently :D

@EmbeddableSuperclass
2

class Product {
3

}
4

@Entity
6

class PersistentProduct extends Product{
7

@Id private long primaryKey;
9

}

Conclusion

After two hours walking around JSR220 persistent API, I figured out that JSR220 mixed ugly into convenience... and it's quite easy to write ugly codes in jsr220...so that we've to insist on using OO and the convenience jsr220 provided to make our domain model as clear as possible.
Although JSR220 is more ugly than hibernate, we could get clearer domain model in jsr220 rather than hibernate, because we could not stand the unly in jsr220...weird way to make us keeping more OO...cool isn't it...

posted @ 2005-12-13 19:25 Raimundox 閱讀(3212) | 評論 (1) | 編輯收藏

A Walk on JSR220

從BJUG的maillist里發掘一個我以前的舊帖出來，嘿嘿

以前我和limo同志做過一個Hibernate技巧情色版....嘿嘿，這次發動大家收集一下J2SE 5和JSR 220里的改進design的tips.我下午試驗JSR220的時候，找到幾個

1. Implement Moment-Interval and Moment-Interval-Details Using Iterable<T>

例子，比如Order和OrderItem，典型的一對多，一般我們這么做

class Order {
2

private List<OrderItem> items;
4

public List<OrderItem> getItems() {
6

}
8

}

在J2SE5里面，

class Order implements Iterable<OrderItem> {
2

private List<OrderItem> items;
4

public Iterator<OrderItem> iterator() {
6

return items.iterator;
7

}
8

public int getItemCount() {
10

}
12

// and addItem removeItem and others
13

}

就可以直接來處理，

for (OrderItem item : order) {
2

}

從某種程度上利用enhanced for的語法，來簡化語法。

trade-off: 不適合多個details 聚合，適合于簡單的moment-interval和moment-interval-details。

2. Annotate Description with @Embeddable, and the Thing it describe with @Entity

例子，Product和ProductDescription

@Embeddable
2

class ProductDescription {
3

private String name;
4

private String description;
5

. and getters and setters
6

}
7

@Entity(access = AccessType.FIELD)
9

class Product {
10

private ProdcutDescription description;
11

}

在JSR220里，如果一個field是embeddable，而且對該field沒有標注為@Transite,以及使用keyword transite,自動按Embedded處理，這一點是很方便的。

這個基本沒發現trade-off

3. Avoid Database Primary Key in Domain Model Using @EmbeddableSuperclass

例子，在hibernate里，總是要給Domain加一個primary key，非常的不爽.
雖然也可以通過繼承結構來避免，但是配置文件太多， JSR220里，通過自動處理的annotation ，可以節約很大的工作量。

@EmbeddableSuperclass
2

class DomainModel {
3

// modeling your model here
4

}
5

@Entity
7

class PersistentDomainModel extends DomainModel {
8

private long primaryKey;
10

}

這個大家就一目了然了

4. Avoid Database Field in Domain Model Using @AttributeOverride

Annotation雖然簡化了開發，但是仍然有一個問題，就是修改mapping的時候需要修改代碼，這個很不好，而且影射的時候需要在domain里硬編碼field
name，這個簡直就是惡心，但是還是由辦法避免的。

@EmbeddableSuperclass
2

class DomainModel {
3

// modeling your model here
4

}
5

@Entity
8

@AttributeOverride(name="property", column=@Column(name="fieldName"))
9

class PersistentDomainModel extends DomainModel {
10

private long primaryKey;
12

}

同樣，通過繼承來隔離技術和Domain，然后在子類里作部署相關的動作。然后把DomainModel和PersistentDomainModel 分包，針對DomainModel編程，就Ok了。這個時候Domain會異常的干凈.....

5. Model Place as Factory

其實這個是一個通則，以前好像也討論過。

public interface Store {
2

Order newOrder();
3

// and others;
4

}

基本上下午2個小時的成果就這么多，我是在嘗試用JSR220 API代替以前我和limo寫的那個珍珠商城訂單部分得到的一些tips。總體而言，JSR220還是挺好的，我們可以很自然的運用一些模式和OO的手段還避免它的不足。同時上述做法在hibernate里也可以做，但是由于比較麻煩，大家一般還是做不到。JSR220里，正是通過它的毛病強迫我們這么做.....（汗），也算體現出約定了。

posted @ 2005-12-12 11:08 Raimundox 閱讀(1991) | 評論 (1) | 編輯收藏

Why Inconsistent Concepts Considered Harmful

Tao Wen , a friend of mine and a new ThoughtWorker, put a comment on my last article.

so, you think the consistent thing means a lot? But how do you think the gracious or elegant feeling mean to the real expressiveness of business requirements? We can see lisp is very successful in researching area because of the simplicity nature inside which is also true to Smalltalk. But why they aren't successful in biz world? I think that is the problem you should further study, "how can the consistent feeling mean something to our everyday programming life?".

First of all, I should admit that I'd never thought about this question before, becasuse I think hankering after consistent concepts is some nature of us. The question enlightens me to thinking deep. Here are my points.

1.Complexity

Inconsistent concepts bring complexity.I'll give two examples.

First one is something in Lisp. Lisp has a very simple computing model called λ Calculation. There are three elements in this computing model: Function, λ Operator and · Operator. λ Operator picks up free variable from the function, and · Operator applies the variable with a concrete value. The whole evaluation-application thing is what we called symbolic algebra in math.For example, if we've a function whose expression is x + y.

((λx (λy . x + y)·3)·4)

=((λx. x+3)·4)

=4 + 3

Since Lisp is kinda implementation of λ Calculation in computer, we could do the same thing in Lisp (and its dialects).

(define f (lambda x (lambda y (+ x y))))

(apply (apply f 3) 4)

or we could use some syntax sugar

(define (f x y) (+ x y))

((f 3) 4)

Most of things in Lisp are focus on evaluation, and the evaluation should be done in a simple consistent way: evaluating, applying value and then returning the value without any change to enviroment. It is the very same way that we do something in math.
But variable assignment was introduced to Lisp, so some functions which change enviroment instead of simple evaluating came to Lisp.For example:

(define (bad-f x y)

(begin

(set! z 5)

(+ x y)))

That bad function changes value of symbol 'z' while evaluating x + y. It is the variable assignment which breaks the consistent concepts. The consistent concepts suggests that function should do and only do evaluation. We must find a more complicated computing model to replace the simple elegant mathematical one.Here inconsistent brings complexities in computing model.

The other example comes from Java. Java is considered to be an object-oriented programming language with single root type system. Conceptually speaking, everything should be an object.But for some perfermance reason, Java has some primitive types (such as int, double, float etc.) too.Those primitive types introduced a algebraic world which paralleled to the object world, and broke the consistent concepts.Althought Java has some wrapper classes for those primtive types, they are not enough for filling the gulf between object and algebra.
We could use new Integer(3) to represent 3 in object world, but we could not simply translate

3 + 4 * 5

new Integer(3) + new Integer(4) * new Integer(5)

Algebraic calculation and object message sending are totally different. Although we could do that in Java 5, it also has lots of differences.Auto-boxing treats object as primitive instead of operator overloading in C++ which treats operator as object message sending.So in my opinion, auto-boxing in java5 is awful. Assginments and storage of primitive type and object have lots inconsistent semantics too. This inconsistent would bring complexity when we use Collection API(Remember Primitive Collection in Commons Collection Project? )

2. Side-Effect

The mainly cause of side-effect is putting some inconsistent concepts together. I'll also give two examples.

First example is the well-known side-effect in functional programming, which is caused by mixing Von-Nouma-style-things into λ Calculation. There are lots of discussion about this topic in functional programming community.It's meanless to repeat that again.

Second example comes from half-blooded object-oriented languages, for we'll find both object-oriented things and procedure-oriented things in these languages, and it'll be much more easier to write code in procedural way instead of object-oriented way.For example, we'd write code like this:

if (order.getState() == Order.CANCEL)
2

do something for cancel;
3

else if(order.getState() == Order.PAID)
4

do something for paid;
5

else if(order.getState() == Order.DELIVERY)
6

do something for delivery

instead of :

public abstract OrderState {
2

protected Order _order;
4

protected OrderState(Order order){
6

_order = order;
7

}
8

public abstract void handler();
10

}
11

class CancelState extends OrderState {
13

public void handler() {
15

do something for cancel;
16

}
17

}
18

order.getState().handle();

For the keywords, it's convenient to write procedural codes as first segment, but for easy maintenance, it's better to write object-oriented codes as the second one.There are two inconsistent way to write code, and the side-effect is depend on how object-oriented the language is. It's more easy to write code like first one in C++ , and more easy to write code like second one in Ruby and Smalltalk. Actually, it's very hard for me to write code like first one in Smalltalk.

3. Constructing Software in a Recursive Way

There is a more large topic, maybe I'd better talk about this latter.

4. Elegance

Some aesthetic feelings comes from consistent concepts.I'll have the feeling of elegance if I could understand some complicated things via some consistent concepts.Take Newtonian System and Maxwell formula for example, they both are the elegant way to resolve problem via few consistent concepts.

posted @ 2005-12-11 01:59 Raimundox 閱讀(2720) | 評論 (1) | 編輯收藏

Why Inconsistent Concepts Considered Harmful

小tao給我找了一個非常好的題目:

我承認以前沒有考慮到這個問題，因為我以為追求概念一致性是一種不言自明的天性。那么為什么要一致性很重要呢？我有這樣一些想法。

1. 復雜性

概念不一致產生首先產生的一個惡果就是復雜性，這里我將舉兩個例子。

第一個關于Lisp的。Lisp本身具有一個很一致很簡單的計算模型——λ 演算。在這個計算模型中，基本元素是函數，λ運算符，·運算符。語義也是簡單明確的，lambda運算符提取出函數中的自由變量，然后再由apply對自由變量賦值。整個計算過程就是函數（符號）求值的過程。例如對于函數x + y，我們可以這樣來求值。

((λx (λy . x + y)·3)·4)

=((λx. x+3)·4)

=4 + 3

由于Lisp多少可以認為是λ 演算的一種實現，我們可以類似寫出Lisp代碼

(define f (lambda x (lambda y (+ x y))))

(apply (apply f 3) 4)

或者更加簡單的寫為

(define (f x y) (+ x y))

(f 3 4)

所有在Lisp中的程序，我們都可以用一種一致的概念來表達，就是符號求值，我們對一個符號應用一些值，然后這個符號完成計算并把結構返回給我們，在計算的過程中，符號對外部環境沒有任何破壞和依賴。但是Lisp中引入了賦值，于是存在一些符號，不僅僅是來計算，同時他們還能改變環境。

(define (bad-f x y)

(begin

(set! z 5)

(+ x y)))

這個函數不僅僅求x + y的值，同時修改了符號Z的值。賦值的引入破壞了函數只求值而不影響環境這個概念的一致性。于是我們不得不尋找一個更加復雜的也更加混亂的計算模型，來代替簡單優雅的λ 演算。于是不一致的概念帶來了思維上的復雜性(不過Lisp中的概念不一致除了產生了復雜之外，還激發了人們對于簡單計算模型的向往從而產生了函數式編程風格，這也是我最愛的編程風格之一)。

概念不一致帶來的復雜性距離我們最近的應該是Java中的簡單類型，Java本身是一個單根的面向對象語言，從概念上講一切都應該是對象，而且由于性能考慮而出現的簡單類型，引入了代數性的世界觀的同時，破壞了面向對象的一致概念。Java中雖然有包裝類來做補償，但是仍然不能彌補概念上的斷裂。我們可以用

new Integer(3)

來代表對象概念中的3，但是

3 + 4 * 5

不能對等的翻譯為:

new Integer(3) + new Integer(4) * new Integer(5)

簡單類型具有的運算符和對象類型的消息發送概念上是不一致的。雖然我們可以在Java 5中使用上述的代碼，但是Java 5的Auto-Boxing更多的把對象類型當作簡單類型進行數據運算，而不是像C++中的運算符重載一樣把數據運算當作一種特殊消息傳遞，雖然語法上有相似的功能，但是概念上大異其趣，對于我這個OO分子而言，Java 5的Auto-Boxing實在是惡心到不行。同時簡單類型和對象類型在賦值語義和存儲模型上也存在很大的不一致，這種不一致性在使用Collection API的時候帶來了一些復雜度。（還記得Commons Collection里那些Primitive Collection吧？）

2.副作用

概念不一致產生的第二個惡果就是副作用，我大概想了一下都有哪些可能的副作用，結果讓我很寒，我能想到的副作用，大多數是由于在另一種模型中引入了馮語言的因素從而造成了概念上的不一致而引起的。其中最為人知的....還是賦值在函數式編程中的副作用...這個在函數式編程社區有很廣泛的討論，我只說一點，為什么命令語言是有害的。

馮語言或者說命令式語言主要用于刻畫對計算機操作的序列，并不關心序列的內在關系。也就是說，我們可以把一些完全沒有聯系的指令寫在一起。因此馮語言在語義上毫無建樹，同時在抽象上也止步于子程序（一砣指令和另一砣指令）。馮語言具有很強的時間耦合性在存儲上也強烈的傾向于線性存儲。目前大多數難處理的問題，可以歸結為計算模型和操作語義的不一致，甚至有些學者認為是馮結構嚴重制約了計算機的發展。因此馮語言被函數社區看作一個很危險的副作用，極力避免之。

概念的不一致產生的副作用在混血的OO語言中也很明顯，尤其是在命令式語言中加入面向對象機制，而且使用面向對象作為類型系統的擴展，使用過程式的方法來控制流程。過程和對象的不一致本身就給了程序員一種暗示，你可以使用對象技術來構造類型系統，然后使用過程的方法來操作他。明顯的副作用們很容易使用過程化程序，從而使得對象帶來的好處被很大的削弱了（當然我們有重構來彌補這個錯誤），比如下面一個例子,我們很容易從寫出下面的代碼：

if (order.getState() == Order.CANCEL)
2

do something for cancel;
3

else if(order.getState() == Order.PAID)
4

do something for paid;
5

else if(order.getState() == Order.DELIVERY)
6

do something for delivery

而不是

public abstract OrderState {
2

protected Order _order;
4

protected OrderState(Order order){
6

_order = order;
7

}
8

public abstract void handler();
10

}
11

class CancelState extends OrderState {
13

public void handler() {
15

do something for cancel;
16

}
17

}
18

order.getState().handle();

因為存在過程性的關鍵字if, while,處于方便的考慮，我們會寫出第一種風格的代碼，而考慮到易于維護，我們應該寫第二種風格的代碼。存在兩種不一致的書寫代碼的風格，這個時候，副作用取決于使用的語言OO的程度，比如在C++里更容易寫出第一種風格的代碼，而在Ruby和Smalltalk中，更容易寫出第二種風格的代碼。

3.遞歸的構造軟件

這個雖然跟概念一致有關，但是一個更大的主題，待續吧。

4.優雅，美感和無名品質

概念的一致性會產生一種優雅的美感，我覺得我們都有這種感覺，如果我們能用一種一致的容易理解且統一的方式來處理多種不同的復雜的問題，那么我們就會覺得這種方法很優雅，也很具有美感。類比物理中的牛頓定律，開普勒定律，麥克斯韋方程，都是這種簡單一致而解決復雜問題的完美示例。我們更容易感覺到一致的感念產生的美感，而不一致的概念往往很難令我欣賞。或許無名品質是我對一致的概念的一種模糊的審美吧。

我大抵能想到的就這么多，不知小tao是否滿意我的答卷。

posted @ 2005-12-10 02:17 Raimundox 閱讀(1139) | 評論 (2) | 編輯收藏

Say sorry to Object-Oriented Methodology

Recently I came to know and started to learn Smalltalk, an age-old pure Object-Oriented programming language. I fell in love with it quickly. Smalltalk is a very small language with some consistent concepts and abundant class libraries. I was puzzled at the very begining, as Smalltalk has very few keywords(maybe 5 I think), and those keywords don't include any control structure(a.k.a if, while, for), how could we write programs? Althougth I know we could implement iterative sturucture via recursion, how about conditional execution? Finally I figured out that Smalltalk provides control strucutre in its class library only using some basic OO concepts. Followings are the codes from Smalltalk class library.

Boolean>>ifTrue: alternativeBlock
2

self subclassResponsibility
3

Boolean>>ifFalse: alternativeBlock
5

self subclassResponsibility
6

"and True and False are subclasses of Boolean."
8

True>>ifTrue: alternativeBlock
10

^alternativeBlock value
11

True>>ifFalse: alternativeBlock
13

^nil
14

False>>ifTrue: alternativeBlock
16

^nil
17

False>>ifFalse: alternativeBlock
19

^alternativeBlock value

and then in some codes, we could do the conditional execution as follows

4 > 3 ifTrue: [Transcript show: 'Hello']

In Smalltalk, everything is Object, so that the code above means sending a message named '>' to an Integer object, whose value is 4, with an Integer object parameter. And '>' would return a Boolean object, and then we sent a message named 'ifTrue' to it. This is a typical usage of State Pattern. Here are the equivalent Java codes.

public class abstract Boolean {
2

public static final TRUE = new True();
3

public static final FALSE = new False();
4

public abstract Object ifTrue(Block aBlock);
6

public abstract Object ifFalse(Block aBlock);
7

}
8

class True extends Boolean {
10

public Object ifTrue(Block aBlock) {
12

return aBlock.execute();
13

}
14

public Object ifFalse(Block aBlock) {
16

return null;
17

}
18

}
19

class False extends Boolean {
21

public Object ifTrue(Block aBlock) {
23

return null;
24

}
25

public Object ifFalse(Block aBlock) {
27

return aBlock.execute();
28

}
29

}
30

public class Integer{
32

public Boolean greaterThan(Integer anInteger) {
34

}
36

}
37

So that we could get the following code

4 〉3 ifTrue: [Transcript show: 'Hello']

which could be translated in Java like this:

new Integer(4).isGreaterThan(new Integer(3)).ifTrue(new BlockClosure() {

public Object value() {

System.out.println("Hello");

return null;

}

});

That's quite simple(some dynamic languages on JVM ,e.g. Groovy, do the same thing), but it indeed brings some profound changes to my thought.

First, considering that 'if'，'for' and 'while' are no longer pre-defined keywords, we could define our own control structures. For example, we could define Order has its own way to do something.

anOrder ifExpired: [ do reactive order]
2

ifCanceled: [do something else]

Taking no account of performance and semantic speaking, there is no difference between the code above and undermentioned:

4 >3 ifTrue: [do something]
2

ifFalse: [do somthing]

More fancy, we could define a new test structure like this:

anOrderTest should: [some assert] when: [do some initalize].

So we could have programmable control structure in Smalltalk ( something like we do in Lisp via continuation:) ), and define our own DSL easily.That's the amazing lightweight syntax feature in Smalltalk!

Second, we could get full capability of Von Nouma Style Programming Language via pure OO concepts.We could construct software in consistent OO concepts.

I began my adventure in Object technology by using C++ in 1995, and then I chose Java as my main working language. All my experiences about OO come from half-blooded OO language.So that for a long time, I thought Object-Oriented Programming is a big patch to imperative languages. The imperative languages are desgined to record the sequence of instruments which are used to manipulate the computer, so they are lack in semantic, and poor in abstraction. Though the Object technology introduces a successful type system and provides some abstraction mechanism, I still feel sucks to program in inconsistent concepts, because I should be careful about keeping programming more in OO-style rather than in procedural-style(something like Domina Model or not, sucks!).

Once I accused Object-Oriented Methodology of all the fault, I blamed imperfection on Object-Oriented Methodology.But now, I found out it's only because that I have little talent and learning in OO, it turned out to be my fault, I should say sorry to Object-Oriented Methodology.

posted @ 2005-12-08 20:39 Raimundox 閱讀(3046) | 評論 (4) | 編輯收藏

Apologize to Object-Oriented Methodology

最近學習了一下Smalltalk，然后深深的喜歡上了這個古老的語言。Smalltalk語言只具有一個很小的語言核心，這個核心由大約10幾個關鍵字和一些基礎的面向對象語義構成。而且關鍵字都是象: . ; ( ) [ ] | := 之類的簡單符號，并沒有提供最基本控制的流程。最開始的時候這讓我很迷惑，雖然循環結構可以用遞歸表示，但是分支怎么辦？然后發現了一個很酷的特性，Smalltalk可以僅僅通過面向對象的語義來實現分支結構（其實就是State Pattern），具體的代碼如下

Boolean>>ifTrue: aBlock
self subclassResponsibility

Boolean>>ifFalse: aBlock
self subclassResponsibility

True>>ifTrue: aBlock
^aBlock value.

True>>ifFalse: aBlock
^nil.

False>>ifTrue: aBlock
^nil.

False>>ifFalse: aBlock
^aBlock value.

然后就可以，

4 〉3 ifTrue: [Transcript show: 'Hello']

因為在Smalltalk里，一切皆對象且從左到右求值，于是4 > 3 返回true，true是類True的唯一實例，然后就可以對它發送消息，ifTrue:，于是調用了^aBlock value.來對傳進去的BlockClosure求值。

下面是類似的java的類似代碼。

public class abstract Boolean {
2

public static final TRUE = new True();
3

public static final FALSE = new False();
4

public abstract Object ifTrue(Block aBlock);
6

public abstract Object ifFalse(Block aBlock);
7

}
8

class True extends Boolean {
10

public Object ifTrue(Block aBlock) {
12

return aBlock.execute();
13

}
14

public Object ifFalse(Block aBlock) {
16

return null;
17

}
18

}
19

class False extends Boolean {
21

public Object ifTrue(Block aBlock) {
23

return null;
24

}
25

public Object ifFalse(Block aBlock) {
27

return aBlock.execute();
28

}
29

}
30

4 〉3 ifTrue: [Transcript show: 'Hello']就可以對應翻譯為:

Boolean condition = new Integer(4).isGreaterThan(new Integer(3));
2

condition.ifTrue(new BlockClosure() {
3

public Object execite() {
4

System.out.println("Hello");
5

return null;
6

}
7

});
8

這個看似簡單的應用，卻帶來了兩個有深刻影響的性質。

第一，由于if,else等結構不再是預定義的語法了，而與我們自己寫的代碼一樣，屬于莫一個類的特定消息，那么也就意味著，我們可以像ifTrue一樣，定義自己的分支結構。
比如
aUser ifNotRegistered: [ do redirect to register page ]
ifExpired: [ do redirect to active page ]

在不考慮性能優化的前提下，Smalltalk認為和
4 >3 ifTrue: [do something]
ifFalse: [do somthing]

是具有一樣的語義的。并不因為Boolean屬于Kernel就有什么不同。因此控制結構也屬于一個可編程的因素，這就是Smalltalk的輕語法特性。

第二，在簡單的語法和完全的面向對象語義中，構造與馮諾依曼式語言完全等價的能力（這種能力在語法上表現為賦值，分支，迭代和子程序調用），于是我們可以完全用一致的面向對象的方法來構造軟件。

很長一段時間以來，我都認為面向對象方法論是在命令式的馮諾依曼式語言的基礎上，通過引入類型系統然后修修補補的得到的，由于馮諾依曼語言式的語言是面向操作層面上的，只是為了更好的刻畫操作計算的一個命令的序列，因此馮語言不可避免的具有不完備的語義，混亂的抽象表達以及等等一系列的問題。作為馮語言的一個大補丁的面向對象方法，我也想當然的以為他雖然有了些進步，但是基礎問題上面還是不能避免的，加之面向對象缺乏一種一致的構造方法，很多時候我們不得不回歸到命令式或者過程式的方法來構造系統，從而破壞掉一種一致清晰的思路，在過程和對象之間不住地權衡（比如Domain Model之爭），這個讓人非常的不爽。在嘗試了一些面向對象語言之后（我是在95年接觸C++的時候開始了解面向對象的，而后主要使用Java做為開發語言），我發現這個問題是很難避免，于是我斷言這是面向對象技術本身的問題，現在看來不過自己所學有限，沒有真正用過純面向對象語言而已，汗顏得很啊。這里向面向對象方法道個歉，嘿嘿。

posted @ 2005-12-08 15:11 Raimundox 閱讀(1930) | 評論 (2) | 編輯收藏

常用鏈接

留言簿(21)

隨筆分類

隨筆檔案

搜索

最新評論

閱讀排行榜

評論排行榜