Re: Liskov Substitution Principle and Abstract Factories
From: Dmitry A. Kazakov (mailbox_at_dmitry-kazakov.de)
Date: 01/14/05
- Next message: H. S. Lahman: "Re: new here, my lang project..."
- Previous message: Ilja Preuß: "Re: up front designs always useless"
- In reply to: Mark Nicholls: "Re: Liskov Substitution Principle and Abstract Factories"
- Next in thread: Mark Nicholls: "Re: Liskov Substitution Principle and Abstract Factories"
- Reply: Mark Nicholls: "Re: Liskov Substitution Principle and Abstract Factories"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 14 Jan 2005 17:55:47 +0100
On Fri, 14 Jan 2005 14:40:58 -0000, Mark Nicholls wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:pg92gmhphg0o.yv7wsr04v0lo$.dlg@40tude.net...
>> On Thu, 13 Jan 2005 18:17:36 -0000, Mark Nicholls wrote:
>>
>>> then how do you get to methods?
>>>
>>> in C++
>>>
>>> void foo(int, char,double)
>>>
>>> maps to
>>>
>>> int::foo(char,double)
>>>
>>> and in a sense that would seem central to OO modeling i.e. you attach
>>> methods to classes, not to cross products of classes.
>>
>> But that's obviously wrong. Methods are attached to tuples of types not to
>> singular types. Otherwise you will never get arithmetic operations,
>> assignment, equality etc right.
>
> now wait.
>
> OK from your context you claim this is obviously wrong....that's fine....but
> what I am saying is it does not seem consistent with OO.
>
> void Dog.Bark() // method on dog
> void Dog.Bark(string what) // method in dog ? or dog cross product
> string ?
>
> I have observed this before and it has worried me but it seems not to worry
> you?
If string will never be inherited from, then you can ignore the issue that
the second Bark should be a method of both. But consider
procedure Talk (X : Animal; Y : Sentence);
Now if Animal is a Bee and Sentence is a Dance, you will agree that it is
not the same as when Animal is a Dog and Sentence is a Bark. Then even with
a Dog, Sentence could be a Wag.
>>> how do you do a class diagram if the methods do not belong to a specific
>>> class, but to a cross product of them?
>>
>> I do not put methods in types anyway when I draw a diagram. To it is
>> relationships between types is of the major interests. Then you can still
>> place a method in a type box if it dispatches on this type, just do not
>> forget that it may also appear in some other boxes.
>
> how utterly bizarre......not bad or wrong....just bizarre.
>
> to me this is ER modelling and overlaying a funtional model (with
> indirection via function pointers) on top.
>
> Bigger, better and more general.....but not what most people would call OO.
Why? It is OO to me. It is still about types. At least according the
definition of OO given by Robert Martin (OO = dynamic polymorphism) is
perfectly OO! Note it is more OO than before, because a subroutine becomes
dispatching in more parameters. So more dispatching, more OO! (:-))
>>> it could be the expected value of 'success' over the cross product of
>>> inputs.
>>>
>>> success would be if expected behaviour = contracted behaviour.
>>
>> Those are not random! For each input the program either fails or not, it is
>> deterministic.
>
> If you do not know (or cannot formally analyse) the implementation of the
> program, then the program is a random variable.
Really? Fermata theorem has been proven, but 5 years ago, was Fermata
theorem = true random then?
> Is the weather deterministic?
> or just so complex as to not submit to complete analysis.
It is not because of complexity. The analysis we could do is based on the
laws (thermodynamics) which are of statistical nature. So any result the
analysis might produce is statistical (= in terms of probability).
>>> you would then have to throw some spurious assumptions at this to enable you
>>> to approximate that....but that's statistics.
>>>
>>> If I build a bridge I am not sure it will stand, but I may be 99.999% sure
>>> it will.....and then the wind blows in a specific direction, at a specific
>>> speed and we discover that it resonates, and falls down.
>>
>> The laws of physics describing behavior of a construction have statistical
>> nature. This is why one can talk about Pr (bridge will stand). The laws of
>> Boolean algebra have nothing to do with statistics. So Pr (program is
>> valid) is sheer nonsense. It is like to talks about Pr (2+2=4).
>
> not until you evaluate the implementation
>
> P(s = 4)
>
> S member of domain { 1+1, 2+1, 3+1 }
>
> s is a member of S with even distribution. (assumption!).
An ungrounded one! Why 2+1 is as likely as 3+1? And there is a simple test.
Start the program again. A truly stochastic system is not predictable. But
a program is perfectly predictable. You do not know the concrete result,
but you know that it will be the same as yesterday. When you have to catch
a lion, you could place a cage in the desert and just wait until it comes,
opens the cage, goes in and then bars the door. The probability of that is
greater than zero. But if you have a buggy program you can wait forever, it
won't become correct.
>>>>>...that's the difference between maths and physics/engineering.
>>>>>
>>>>> not ideal....no....but this is the reality.
>>>>
>>>> You cannot apply any theory without reasonable justification.
>>>
>>> I have no model as yet.
>>>
>>> naively
>>>
>>> if a program worked yesterday, and last week, and for the last 3 years, you
>>> would expect it to work tomorrow.
>>
>> On different data? Come on, it is like to expect that if test A passed then
>> the test B would too. OK, it is in human's nature to hope in that, but it
>> has nothing to do with the reality.
>
> yes it does.
>
> If you have a calculator and you type in 10,000 different combination of x +
> y....
>
> will the 10,001 work..
>
> you claim that you do not know.
>
> I claim P(10,001 works) is pretty high probably about 0.9999 based on a
> naive model in my head of calculators and how they work.
No, it is the same as follows. Let I write a number 1..100 on a piece of
paper, but I do not show you. You have to guess it, according to some model
(actually any model) in your head. Does this make the number random? Nope.
It is a solid, concrete number. The processes which lead you to a decision
what number it might be are random, not the number itself. Same with the
program. You can guess about it. Your guess might be random or not. But the
program itself is still deterministically right or not.
>>> It is not proof, but you do this every day, you have a model in your head
>>> that says so.
>>
>> Right. This is what I meant. The randomness lies in our heads, not in the
>> software. So the "theory" describes not the distribution of faults, but the
>> distribution of our beliefs in the software. Good to fake up our customers,
>> but no other use. Just psychotherapy, as I said before.
>
> But are not my beliefs largely consistent with observations made in the real
> world (hopefully).
>
> the 'theory' in my head is based on beliefs yes...but these beliefs are not
> completely irrational and worthless.
>
> to say P(X = x) = 0.99 is not worthless just because 1 time in a hundred it
> is false.
>
> Even P(P(X = x) = 0.99)....which is what you are questioning....i.e. the
> probablity that the model does indeed reflect some sort of reality.
>
> (actually this is largely pertinent to the nature of legal trials in the
> UK.....'expert witnesses' have oft claimed things like P(second child dies
> of cot death) = 0.00000001 ...i.e. guilty of murder.....only to find that
> the probabilty that the model is in fact flawed is far less....and in
> hindsight closer to 1.....so the question becomes a conditional one P(second
> child dies of cot death / experts model actually is correct)...which is a
> much bigger number)......i.e. the opinion of an expert cannot be worth more
> that your opinion of experts in general....which aint much.
But here we have similarity of sampled cases. In the case of some given
program there is no any sample set. Your observations might be true for
some class of programs, actually projects. But you do not know whether this
concrete program belongs to the class and what are properties of the class.
Nobody tried to prove any statistical hypotheses on such shaky basis. And
again any result will tell something about the probability that some team
of programmer will produce a correct program. This will tell nothing about
whether they actually had! Or even better, let you are a manager of a coin
tossing project. How many times you have to toss the coin to get the head
with the probability 1?
A true statistical model would be a random code generator. Then you have to
decide whether the code is correct. We could agree that is far more easy
just to throw that garbage away and write it from scratch! (:-))
>>> If you can produce a reasonable subset of the space of inputs, and relate
>>> those to the set of inputs likely to happen in a given program, then you
>>> have the basis for a statistical indicator.
>>
>> Huh. To do this you have to exactly know how the program behaves. But this
>> is what you are trying to describe! Otherwise, I would claim that the
>> program behaves independently on different inputs. But how can you imply
>> any program behavior on untested inputs? That's the first question. The
>> second question is how do you know that the produced subset of inputs
>> reflects the customer's set of inputs? We know too well that all programs
>> are used in a way nobody (either programmer or customer) predicted during
>> development.
>
> true....I'm not claiming it is easy...or even that sensible....just a
> possibility when all else fails.
>
> take the calculator example...
>
> take a 10,000 calculators at random and run the same test i.e. type 10,000
> random x+y combinations, and verify the answer and then verify that the
> calculator is working and work out the distrubution of the 10,001 test
> working on the 10,001 calculator against the 10,001 test on the 10,000 and
> the results from the previous tests).
>
> you now have a statistical model (possibly flawed) that will give you the
> probability of taking a calculator at random and type 1+1 and getting
> 2.....not proof, but I would expect that it would actually be highly
> accurate.......in fact we could statistically test the accuracy of this
> method and apply it to other things....e.g. washing machines.
You can calculate the probability that you can catch the calculator on
overflow. Actually it is quite low. Now, how many different + makes a
program at different occasion per millisecond? Statistically your
predictions are worth of nothing, if it were as you tell. But actually you
are cheating. Because you *know* how the calculator works. Same with the
programs. You saw the design, you know the programmers, you designed the
tests etc. It is not statistics. For good, I'd say, otherwise nothing would
ever work!
>>>> This is what polymorphic programs are. You have some polymorphic Pi defined
>>>> on the class A'Class. The class includes A, B and all other derived types.
>>>> P2 is defined on A'Class. It has an implementation for A and another for B.
>>>> P1 is also polymorphic, but we didn't override it for B, so B uses the
>>>> implementation given for A.
>>>
>>> I think I'm catching on, are you viewing P as a polymorhic type as well as
>>> A?
>>
>> The polymorphic type is A'Class = { x | x in descendant of A }. In the
>> terminology I use polymorphic type = class.
>>
>> Virtual = dispatching = dynamically polymorphic P1 and P2 are defined on
>> A'Class, not on A or B. A::P1 and B::P1i are parts of P1.
>
> oh no we've been here before, and I didn't understand then.
>
> Ok is it the equivalent as me saying......
>
> interface/base class IWindow
>
> P(IWindow)....i.e. P is defined in terms of IWindow
No, it is defined in terms of IWindow'Class. Only its implementation for
IWindow is in terms of IWindow. [Though in C++ it is crippled, because it
re-dispatches from methods. But that is C++'s design flaw. ]
> but MSWindow is a subtype(!) of IWindow, LinuxWindow is a subtype(!) of
> window.
Yes, MSWindow is a subtype, i.e. an object of MSWindow is also an instance
of IWindow'Class, note it is not an instance of IWindow. Substitutability
is achieved via dispatch:
void IWindow'Class::P (Object)
{
switch (Object's actual type)
{
case IWindow :
IWindow::P ((IWindow) Object);
break;
case MSWindow :
MSWindow::P ((MSWindow) Object);
break;
case LinuxWindow :
LinuxWindow::P ((LinuxWindow) Object);
break;
...
>> And yes you can present a set of working Pi, but it would not help. Because
>> let somebody have written P, is P in {Pi}? It is undecidable.
>
> If it only contains orthogonal elements (we need some sort of way of
> modelling this, and it may be impossible) of the basis set then it must
> belong to the set.
>
> i.e. is the vector (2,3) a 2 dimensional vector.
>
> if and only if we can express it in the form x(1,0) + y(0,1)
>
> (2,3) = 2(1,0) + 3(0,1).......yes!
That (Cartesian product) does not warranty substitutability. C-E is the
example. Derive Ellipse from Circle and you will see. [ In other post I am
trying to explain why Circle->Ellipse mapping, or Real->Complex one are not
enough for substitutability. In general case you will need isomorphism. ]
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
- Next message: H. S. Lahman: "Re: new here, my lang project..."
- Previous message: Ilja Preuß: "Re: up front designs always useless"
- In reply to: Mark Nicholls: "Re: Liskov Substitution Principle and Abstract Factories"
- Next in thread: Mark Nicholls: "Re: Liskov Substitution Principle and Abstract Factories"
- Reply: Mark Nicholls: "Re: Liskov Substitution Principle and Abstract Factories"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
