聽說COM違反OOP的概念？？？
水瓶殺手....
真的嗎？？
若是如此....是為什麼會違反OOㄋ？？
哪位高手能解釋一下...
--
--
[1m [37m 特技場上.....是我飛躍的地方...
越飛越高.....當然跌得也越痛
唯有火箭的速度加上瘋狂的信心
JUST CAN.....Win
[36m [1m速度 [37m [01m+ [01m [36m信心 [37m [01m= [01m [5m [33mYaaa Hoooooooooooooooooo
--
[1;33m※ Origin: [36m奇摩 大摩域 [37m<telnet://bbs.kimo.com.tw> [m
[1;35m◆ From: [1;32m163.30.57.170 [m
Cheng-jen Tang
"水瓶殺手...." <itis...@bbs.kimo.com.tw> wrote in message
news:3ebCVd$p...@bbs.kimo.com.tw...
>
> 真的嗎？？
> 若是如此....是為什麼會違反OOㄋ？？
> 哪位高手能解釋一下...
個人認為比較合適的說法是 兩種 (CBD 及 OOT )是相類卻
又不同的發展方法 所以沒有甚麼違反不違反的問題
假如 有興趣的話 可以看看下述參考文獻 兩者的一些特性
略述於下:
CBD: Component-based Development
如 使用 COM object 來發展程式
There are arguments regarding whether or not CBD is just another deviation
of object technology. An obvious reason is that object technology and CBD
pursue the same basic aims, which is to build software from reusable pieces.
However, object technology is domain-driven, which usually leads to designs
based on domain objects. Object technology assumes that developers build an
application from scratch, and they incorporate reuse of existing
architectures and components much later (cf. CBD) in the development process
(if at all) [1]. This results in that object technology is very successful
for implementing and packaging components, but it only offers limited
abstractions for flexibly connecting components and explicitly representing
architectures in applications. After all, object technology exposes class
hierarchies, not object interactions. In addition, developers typically
distribute the task of interconnecting objects amongst the objects
themselves.
The traditional object technology vision is, at best, vague on the subject
of reuse: Objects would appear as by-products of software development, a
market would emerge, and programmers would become producers and consumers of
objects. However, there were two major roadblocks. Most OOP language
systems, including C++, lack the means to package and distribute objects
effectively in binary form. More subtly, the skills and disciplines needed
to build components are often quite different from those needed to use them
[2].
On the other hand, CBD concerns on different objectives. First, CBD focuses
on the issues regarding the software construction and component
interpretability mechanisms. Some researchers suggest that to successfully
plug components together, it is necessary that [3]:
i) The interface of each component matches the expectations of the other
components.
ii) The “contracts” between the components are well defined.
Therefore, CBD depends on adherence to restricted, plug-compatible
interfaces and standard interaction protocols.
Furthermore, CBD concerns how to guarantee the quality of the components.
Antoine Beugnard, Jean-Marc Jezequel, Noel Plouzeau, and Damien Watkins [4]
took a closer look at the notion of contract beyond the original correctness
contract concept, and distinguishes component contracts into four levels:
i) Basic contracts, which are simple component interfaces, list operations
and their signatures (types of inputs and outputs) without semantic
properties.
ii) Behavioral contracts define the interface behavior for components.
iii) Synchronization contracts specify the global behavior of components in
terms of synchronizations amongst method invocations.
iv) Quality-of-service contracts quantify the expected behavior of
components, or offer the means to negotiate these quantified values.
Object-oriented methods encourage developers to declare and define classes
that reflect the objects of the problem domain, but this does not
necessarily produce software applications “contract aware”. In particular,
object-oriented methods do not typically lead to designs that make a clear
separation between computational and compositional aspects [5]. However,
components assume object technology, they use object technology, and they
promote object technology [6]. As David A. Taylor [7] cited: “Like
siblings, objects and components squabble about their differences but have
more in common than they’re willing to admit.” For example, I3S uses the
supposed-to-be object-oriented notations – UML as the notations for
constructing the design specifications of component-based applications.
Although UML has some shortcomings in this regard, with some appropriate
additions, CBD tools can use these notations as well.
References:
[1] T. Reenskaug, “Working with Objects: The OOram Software Engineering
Method,” Manning Publications, 1996.
[2] J. Udell, “Componentware,” Byte, Vol. 19, No. 5, pp. 46-56, May 1994.
[3] J. Schneider, “Components, Scripts, and Glue: A conceptual framework
for software composition,” PhD Thesis, University of Bern, Institute of
Computer Science and Applied Mathematics, October 1999.
[4] A. Beugnard, J. Jezequel, N, Plouzeau, and D. Watkins, “Making
Components Contract Aware,” IEEE Computer, Vol. 32, No.7, pp. 38-44, July
1999.
[5] J. Schneider and O. Nierstrasz, “Components, Scripts and Glue,”
Software Architectures -- Advances and Applications, pp. 13-25, Springer,
1999.
[6] B. Meyer, “Component and Object Technology: A Really Good Idea,” IEEE
Computer, Vol. 32, No. 12, pp. 144-147, December 1999.
[7] D. Taylor, “Are Objects Obsolete?” Component Strategies, Vol. 1, No.
1, pp. 16- 17, July 1998.
Mm..
不用解釋的太複雜...
簡單說吧...
因為 COM 是希望 Design in Stateless Object.
所以似乎是違反了 Object (Stateful ) 的感覺
but .. 這是不一定的..
應該 stateful 配合 stateless . 才能發揮最佳的彈性. :)
《 在 itis...@bbs.kimo.com.tw (水瓶殺手....) 的大作中提到: 》
: 真的嗎？？
: 若是如此....是為什麼會違反OOㄋ？？
: 哪位高手能解釋一下...
--
[1;33mMain [1;37m( ICQ:2883897 ) [1;33m{ polo...@msa.hinet.net }
" 當我說喜歡你的時候 又關你什麼事呢? "
[0m
[m [1;37m※ 來源:‧蛋捲廣場 bbs.tku.edu.tw‧[FROM: 203.69.219.2] [m
Cheng-jen Tang
"Mm.." <polocl...@bbs.tku.edu.tw> wrote in message
news:3ec0b9$4...@bbs.tku.edu.tw...
> 不用解釋的太複雜...
> 簡單說吧...
>
> 因為 COM 是希望 Design in Stateless Object.
基本上 這是 COM 的 最大誤解之一
的確 Stateless Objects 用在 MTS 裡比較簡單
但 根據 M$ (Don Box) 的講法 :
...
An object is state + behavior. This is true in most object-oriented
languages, and is true in the COM programming model. This is also true in
the MTS programming model.
...
COM 不是 Stateless 而是 State-ignorant 可是 states
可以 被 implied by behavior: i.e. Get/Set Properties
...
COM has been a state-ignorant programming model. COM knows only about
behavior.
... (Don Box)