Re: object system...

Responding to Grizlyk...

If yes, then you are wrong, because there are even no one OO language
with perfect perfomance.
There is no 3GL that provides perfect performance;
for that you need machine language.

I disagree. General purpose languages of xGL are not desined to
decrease performance of previous (x-1)GL.

It's true that they aren't *designed* to be slower. But the price of abstraction is performance. Any nontrivial C program with be 30-50% slower than hand-tuned Assembly. Any C++ program will be 50-200% slower than the C program.


We use OOPLs for the abstraction and
logical decoupling they provide, not performance.

I disagree. We use OO desing to remove all of the operations, that can
be done automatically, by compler, without any performance lost, not
in order to use abstraction as self-target.

Say, what?!? Abstraction is used to boost developer productivity. Logical decoupling is used to boost developer productivity during maintenance. Both are indirectly used to improve reliability. Performance is the price one pays for the productivity and reliability gains.

In the early '60s a 1 MLOC application was regarded as gigantic and I recall an estimate that it would require 1000 engineers working for a decade to complete such an application. And defect rates in those days were in the area of 150 defects/KLOC.

We've come a long way since then so that MLOC applications are small-medium size, they are developed by a group of 8-20 engineers in a year, and defect rates are down in the 0.5 defects/KLOC range. But you need a desktop with the computing power of a 1984 mainframe to run exactly the same spread*** that ran in 1984 on a TRS-80 or an Apple I.

We just don't notice the performance hits paid for greater productivity because Moore's Law has been working for hardware for nearly half a century.


What? Why? Incredibly. Any void concrete implementation is the best of
all others, but unfortunately nearly always unreachable.
Note that an object is defined by its responsibilities. By definition
those responsibilities are obligations to know or do something. The
interface represents access to those obligations. So the object should
never have an interface to access not doing something.

"The interface represents access to those obligations" - I deisagree.
It is possible, we argue about terms only.

OK, let' try this from the Dictionary of Object Technology:

"Interface n. 1. (a) any specification of the boundary of something in terms of possible interactions or properties that are visible across that boundary. (b) the visible, outside, user view of something. 2. the messages to which an object can respond."

That sounds a whole lot like access to me. Also note that in UML an Interface is a separate model element from a Class. That Interface element provides an explicit mapping between incoming messages and the operations or attributes of the Class.

"Programming based on interfaces" is a key of OO desing. Interface is
primary part of an abstraction. An appearence of an abstraction linked
with its interface, not with its implementation. Speaking about an
abstraction we are speaking about its interface.

This is kind of Motherhood & Apple Pie. Encapsulation is a critical notion in the OO paradigm. So collaborations should be defined in terms of interfaces. The point is...?


So "interface" defines all logical properties of its abstraction (what
to do): responsibilities, access, protocols (sequences of usage) etc.

The dividing between interface ("what to do") and implementation
("how to do") is artificial, not natural of nature, but anyway
"object" never can "define its responsibilities", because "object" is
an instance of interface.

Ah. I see. You are a type maven. B-) So we need a little primer here on OOA/D.

Types do not even exist in OOA/D (other than knowledge ADTs). OOA/D is based on class systems rather than type systems. The 3GL type systems are a compromise with the hardware computational models. As a result they do not reflect a number of fundamental OO design issues.

The most important such issue in this thread context is the separation of message and method. Because 3GLs all employ procedural message passing there is no distinction; the message is simply the procedure signature. Since we name procedures by what they do, the message becomes a very specific imperative to do something (Do This). Unfortunately, that implies that the sender of the message knows (A) that the receiver exists, (B) that the receiver does something specific, and (C) that doing it is the next thing to do in the solution. All of those things trash OO encapsulation and implementation hiding because it makes it easy to construct the sender so that it depends on what the receiver does.

[For example, in a well-formed OO application only knowledge attribute getters should return a value. If a behavior method returns a value that creates an instant dependency between the caller and implementation of the receiver. That is, the caller depends on the *how* the receiver computed the value because the value must be correct for the caller's own specification of what it must do. Note that the 3GL type systems can't enforce that distinction because the type distinction between function vs. procedure is orthogonal to the semantics of knowledge vs. behavior responsibilities.]

Contrast that with OOA/D where message and method are separated. Now a message is an announcement of something the sender did to change the state of the solution (I'm Done). All the sender needs to understand is what it did. So there can be no dependency in its implementation on what will happen. It is up to the developer to connect the dots of flow of control so that the message goes to some object that cares about the state change and can respond appropriately. (In UML that is done at an entirely different level of abstraction in an Interaction Diagram.) Thus the separation of message and method is one of the core mechanisms of OO decoupling.

When message and method are separated, the role of the interface is different. It exists to provide a mapping between announcement messages and responses. That's why Interface is a separate model element from the Class it encapsulates in UML. In OOA/D class systems, the Class defines the responsibilities that an object has without regard to context; it describes the intrinsic nature of the object. That nature is mapped to context through the interface.

But when message and method are coincident as in the 3GL type systems, there is no distinction between its intrinsic nature and how it is viewed in the context of the solution. So in 3GL type systems the interface also defines what the object is.

That's why it is important to understand OOA/D prior to launching into OOPL coding. If one gets the OOA/D right, then the sender method will not depend on what the receiver does because it doesn't know anything about the receiver. Then the fact that the 3GL type systems have trashed OO decoupling is not a problem.

<aside>
Alas, the 3GL type systems are the root of another problem, physical coupling (i.e., what the compiler or interpreter must know about the receiver to write correct machine language for the message sender). The OOPLs do a good job of logical decoupling but they do a terrible job on physical decoupling. The result is that to make an OOPL program maintainable one has to do dependency management refactoring *after* the problem solution is correct. Such refactoring is completely unnecessary for OOA/D models. Corollary: doing a rigorous OOA/D model will usually minimize the amount of dependency management refactoring required during OOP.
</aside>


--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

H. S. Lahman
H.lahman@xxxxxxxxxxx
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
.

Quantcast