Re: Liskov Substitution Principle and Abstract Factories
From: Dmitry A. Kazakov (mailbox_at_dmitry-kazakov.de)
Date: 01/21/05
- Next message: frebe: "Re: What is an OODBMS?"
- Previous message: Vijay: "Re: Empty interface and polymorphism"
- 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"
- Reply: Robert C. Martin: "Re: Liskov Substitution Principle and Abstract Factories"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 21 Jan 2005 12:03:05 +0100
On Wed, 19 Jan 2005 13:22:38 -0000, Mark Nicholls wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:3zevehgd1j6f$.8hpzxjpt8et2$.dlg@40tude.net...
>> On Tue, 18 Jan 2005 10:56:41 -0000, Mark Nicholls wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:qukbppdmnots.lw5s8wh9kdms$.dlg@40tude.net...
>>>> On Mon, 17 Jan 2005 14:21:24 -0000, Mark Nicholls wrote:
>>
>> Call it intuition, but it is
>> not a probability. Let you be 99% sure that God exists? What could follow
>> from that?
>
> I would probably start going to church.......at least 99 Sundays out of 100.
Like a man who regularly visited church, synagogue and mosque just in case,
somebody of them is right. Unfortunately gods of all religions are jealous,
they don't tolerate unfaithfulness... (:-))
>>>>>>>>> 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.
>>>>>
>>>>> Thermodynamics (as far as I remember) is not statiscal.
>>>>
>>>> It is. Temperature, pressure, density, all are statistically defined
>>>> values.
>>>
>>> I seem to remember lots of differential equations.......
>>>
>>> I would assume that temperature is some sort of absolutely defined sum of
>>> kinetic energy of particles.....but because we cannot practically observe
>>> that we make assumptions.
>>
>> I remotely remember that all laws of thermodynamics are statistical.
>> Nothing prevents the gas molecules to separate themselves so that cold and
>> hot ones will gather on different ends of a tube. Yet, an engine built on
>> this principle is impossible, statistically impossible. Mechanically it is
>> perfect: catch a Maxwell daemon and here you are.
>
> Are you saying that the laws of thermodynamics and mechanics are
> contradictory?
Honestly, I do not know, if one could derive thermodynamics from Newton
laws assuming that molecules were ideal billiard-balls. It is far beyond my
knowledge. I only suppose that it might be very non-trivial or even
impossible. Compare with deriving arithmetic from the set theory.
>> Different laws. You are outside of thermodynamics then.
>
> If they are consistent (I would hope), then I should be able to create a
> mechanical model that absolutely predicts the weather (given absolute
> data...which is dubious).
I do not think you will be able to do so. You have to track down
interaction of particles, these are controlled by chemistry, physical
chemistry and in the end by quantum mechanics, which is inherently
stochastic. So the macro system will be random as well. Therefore the
weather is truly random, it is not a fake randomness of *random* guessing
about weather.
>> We cannot apply statistics just because something is impractical to do
>> right.
>
> really?
> why not?
Because it might turn impractical as well. Would you use statistics to
manage your bank account? If you do not know the right way to do something,
you do not know it. Statistics is just a way to do something you know to be
done with statistics. (:-))
> Is this not the case with thermodynamics?
No, because the laws of thermodynamics were proven (not falsified) by
physicists. They have a definite area of applicability etc. Possibly
similar thing could be done for software development, but as I said before
I do not believe it that.
>> No. Prime numbers are good for pseudo-random generators, but they are not
>> random. "Pseudo" vs. "truly" is crucial difference. A truly random sequence
>> cannot be evaluated by no way. Prime numbers can be. The complexity of the
>> method is irrelevant here. That's the axiomatic of mathematical statistics.
>> The theory of hidden parameter, you are referring, if true, would make
>> statistics inapplicable, altogether.
>
> but nothing is truly random (or at least very little, unless we start
> talking about quantum mechanics, and then I would suggest that if you cannot
> see in the box, is the cat alive or dead?, if you cannot see inside the
> program, does it work or not?).
It is a philosophical position, you know. In my view things are truly
random. I'm with Bohr, against Einstein here. I do not trust in the theory
of hidden parameter.
>>> Rather like a program.
>>>
>>> I did say there were lots of problems....the chaotic nature make small
>>> errors magnify, I accept, but even so I 'know' its not going to be 29
>>> degrees C tomorrow in London.
>>
>> Ah, but statistically it is well possible! The probability is not 0.
>
> no, but it is something like 0.00001%
>
> thats useful
>
> If the probability that program P does XYZ, 99.9999%, thats pretty
> useful....good enough in fact, for almost any purpose.
Ah, here we go again! (:-)) In my view there is no probability that P does
XYZ. There is only a probability that your random guess about P is true or
false. It does not depend on P, it depends solely on your ability to guess.
> If warming up is better than being cold, then do it.
> If it is impossible to overtake, but it's useful to be a little closer, then
> start running.
Yep, NASA should train astronauts to climb trees. After all that would
bring them closer to the Moon. (:-))
> I create a model......
> I make statistical predictions.....
> someone questions the model.....(using a statistical model)
> and then makes statisical statements about the model.
>
> so....
...nobody could tell you what does it mean.
>>>>>> But a program is perfectly predictable.
>>>>>
>>>>> Once it is completely observed, before the observation it isn't.
>>>>
>>>> No, it is a property of a program to be predictable. You know that y=f(x),
>>>> i.e. that for any given x there is one y. If f were random you could not
>>>> say so. You would have Pr(y|x) instead.
>>>
>>> you can!
>>>
>>> For it to be random, does not mean it is utterly unpredictable.
>>>
>>> Toss a coin.....it comes out head or tail....it is random, yet there is only
>>> 1 answer and that answer is specifically defined to be a member of a set of
>>> 2.
>>
>> So you have Pr (Head | try no.=n). You do not have Head (n)
>
> I do not understand Head (n)..
The function that for given n returns Head = true or false.
> If I do not know how head/tail is distributed...I run an experiment to
> statistically guess the value.
>
> If it comes up 1,000,000 times head and 1 tail....I think I could probably
> reasonably safely say it is not a 'fair' coin.
>
> If you ask me what it will be when you toss it again, I will say
>
> "heads"
>
> I do not 'know', but heads will probably be good enough for my
> purposes.....and probably be correct.
1. How do you define the purposes?
2. Why do you know that it is good enough?
3. How do you know that the coin does not have a counter set to 1,000,000.
BTW, navy widely uses pass-counters for their mines. Would you experiment
with such mines?
4. And finally, how "probably correct" is any better than "probably
'head'"?
See above. As Littlewood noted probability introduces vicious circle. Once
you get in, there is no way out.
>> Many, many are quite sceptical about Bayesian approach. But that's another
>> story.
>
> The whole of statistics is dubious in some sense, yet its good enough for us
> a lot of the time.
To be consistent, you should say: there is a probability that it is good
for us. (:-))
> maybe the question about program correctness is more like
>
> Pr (amount of bucks > Y)
>
> than
>
> Pr (X = right number)
Alas. But that's rather a sociological problem.
> maybe the question is
>
> Pr(Program is fit for purpose)
>
> rather than
>
> Pr(that pressing button OK, will do ABC)
The problem is how to define the purpose. A usual way is: purpose =
fulfills the requirements, and requirements are sort of "pressing OK does
ABC". How would you do it otherwise?
>> So you have to
>> sample a large statistics to test some hypothesis. But with in the case of
>> a program the size of the statistics needed (provided some very strong
>> assumptions I don't believe be true) is so giant, that you will be unable
>> to estimate anything. See also below.
>
> I think we do it now.
>
> I think UAT is exactly this, you do not echaustively test an application,
> you make it jump through some predefined hoops, and then make a huge leap
> to......its probably good enough then.
Psychotherapy...
>>>> But the jump from random behavior of people to random
>>>> behavior of programs to too big too me. I do not believe it could be
>>>> feasible.
>>>
>>> I do not see the problem.
>>>
>>> A team of mathematicians write formula to prove the twin prime conjecture.
>>>
>>> P(team proves it) = P(the proof is correct).
>>>
>>> before observation of the proof.
>>>
>>> P(team writes some perfect code) = P(code is correct) (=0)
>>
>> Or
>>
>> Pr (Code is correct | Coin = Head) (:-))
>
> So you do not accept that the 'nature' of the programming team has any
> statistical influence on the 'nature' of their output!?!
No. What influence do you have on your date of birth? A program P is either
correct or not, if we talk about an output. If you consider team outputs as
a random variable [+the requirements (the problem) are fixed], then it is a
different thing. If so, then in my view the random component in output of a
team would be quite low. It wasn't so at the dawn of programming, but now
things like typo errors have very low chance to slip undetected into
delivery. So in my view the output might be uncertain, but not random. This
is why I wouldn't apply statistics here. The fuzzy set theory would fit
much better here, IMO.
> So there must be a model in my head, and yours that says that programs are
> not random, and that they are statistically dependent on the quality of the
> team.
No, no. They are independent on anything. The number 1 does not depend on a
random generator that might time to time spit it out. [ The quality of the
team describes nothing but its programmers. ]
>> No. Actually Pr (this proof is correct | good) = Pr (this proof is correct
>>| bad) = either 0 or 1.
>
> before observation it is not.
Huh, the fundamental axiom of the probability theory is that observations
do not influence the probabilities.
>> What you meant was probably:
>>
>> Pr (A randomly selected proof given by a Mr. Good is correct) >
>> Pr (A randomly selected proof given by a Mr. Bad is correct)
>
> yes....I think.
>
>> This tells something about Mr. Good and Mr. Bad, but nothing about a
>> concrete proof which is always either correct or not. To avoid meaningless
>> word games you have to present the set of outcomes. For example.
>
>> Consider
>> the problem A and the set of all possible programs {Pq}. Then a P from {Pq}
>> either solves A or not.
>
> yes
>
>> Further you can talk about a set of teams {Xi} of
>> programmers. The process is: you randomly select a team X from {Xi} and
>> this team writes some P(X) which either solves A or not, i.e. A(P(X)) is
>> either true or false.
>
> yes
>
> so lets have team that is always wrong, and one that is perfect.
>
> X0 and X1
>
> Pr(A(P(X0)) = true) = 0
> Pr(A(P(X1)) = true) = 1
>
>> As you see it brings nothing. So you have (and you
>> actually keep on trying to do it) to talk about some set of problems {Aj}.
>> Then you claim that if the team X is fixed and a problem A from {Aj} is
>> randomly selected, then there is Pr(A(P(X)))= the probability that X will
>> solve a randomly chosen problem.
>
> so now lets have 2 problems A1 and A2, and we don't know the team i.e. the
> team is some Xi
>
> answers to A1 are P1 and answers of A2 are P2.
>
> Pr(A2(P2(Xi)) = true | A1(P1(Xi)) = true) = 1 !
>
> i.e.
>
> Pr(A2(P2(Xi)) = true | A1(P1(Xi)) = true) = Pr((A2(P2(Xi)) = true)
> intersection (A1(P1(Xi)) = true)) / Pr(A1(P1(Xi)) = true)
>
> but
>
> A2(P2(Xi)) = true) => A1(P1(Xi)) = true)
> and
> A1(P1(Xi)) = true) => A2(P2(Xi)) = true)
For any P1 and P2? There is no such team! (namely X1)
> => Pr((A2(P2(Xi)) = true) intersection (A1(P1(Xi)) = true)) = Pr(A1(P1(Xi))
> = true) = Pr(A2(P2(Xi)) = true)
>
> => Pr((A2(P2(Xi)) = true) intersection (A1(P1(Xi)) = true)) / Pr(A1(P1(Xi))
> = true) = Pr(A1(P1(Xi)) = true) / Pr(A1(P1(Xi)) = true) = 1
>
> so given an observation about one problem, we can deduce something about
> another (based on a model about team Xi).
Of course, if you know how A1 and A2 are related in terms of Pi(Xi) and
Pj(Xj), then you could tell something about what would happen if you
randomly select a team. Though I do not see how this might help. Because
judgement about similarity of problems is even more harder than judgement
about a given program. It should be quite obvious, because the former is
defined through the latter.
> (Its really is 15 years since I've done anything like this...and I wasn't
> that great at it at the time, so there may be a glaring mistake).
>
>> This value depends on the set {Ai} which
>> fine structure is absolutely unknown. You can claim that An is similar to
>> Am, but where do you know it from?
>
> we do this every day.....
Which at best proves nothing but our ignorance. We just do not know, so we
are guessing. But from guessing to probability is a wast ocean of knowledge
we simply do not possess.
> We do not need to know the whole set {Ai}, just those which we see in
> everyday (experimental) life, in fact the nature of programming means that
> the Ai's may be highly correlated in a specific program....i.e. if the data
> access layer doesn't work, no access from the client, will work, so these
> 'problem' are in the real world highly correlated.
>
> A = false => B = false.
As I said, that is guessing, which is even less likely to be right than
guessing about program correctness. You can substitute (in LSP sense, mind
you! (:-)) a more complex problem for a less complex one, that would not
solve either.
>> That should follow from forall (good?)
>> Xk there is a correlation between A(P(Xk)). Where that follows? This all is
>> built on the sand, you know.
>
> statistics generally are, but it only needs to be good enough.
And good enough is quite precisely defined in Student-criteria and
likewise. Applicability of those, first, requires some assumptions which I
don't believe be satisfied, and secondly it requires sizes of statistics,
you will never be able get.
>> OK, if the program length is 2Mbytes then there are 2**(2**160) outcomes.
>> This is damn many.
>
> you are viewing the set of all programs (given a problem) as being evenly
> distributed....that may not be true.
Which makes things only worse...
> a normal distribution mean 0, variance 1.....the set of outcomes is the set
> R, but I can say 90% of the time it will be between (-1,+1).
There are strong evidences that the distribution isn't normal. Should we
map programs to the set of integer numbers by writing down the program's
binary code, then it is quite obvious that the distribution will be awfully
bad. Maybe there are better mappings, who knows, but the problem of finding
and evaluating them is in order of magnitude more complex than the two
problems mentioned before. We are mounting complexity over complexity, for
nothing.
>> I suppose it is much more than the total number of
>> particles in the universe. You could claim that the distribution in uneven,
>> OK, you know which it is?
>
> no, run the experiment, make the observations, build a model, make
> predictions, if it's evenly distributed your predictions wont be very
> valuable, if it isn't, they will be.
No chance. There is no need to try, because the size of any possible
statistics will be too small.
>>>> Even more difficult is to judge about its distribution.
>>>
>>> If the program is produced randomly yes, if it's produced by people no.
>>
>> Maybe, but you do not know how people do it!
>
> I don't need to.
>
> I just need to observer they're previous outputs and see how they are
> correlated (if at all).
Sample size kills this too.
>>>>> i.e. I can substiture complex for real
>>>>
>>>> You cannot in + : R x R -> R. But you can in Read : File -> R
>>>
>>> this is what's confusing to me.
>>>
>>> // dispatching on all parameters.....?
>>
>> Non-dispatching. With dispatching it would be better: you should not
>> inherit R::+, that would be non-substitutable, but you could override it
>> with +: C x C -> C and so get it right.
>
> I'm still not 100% with this, you would probably take 10 minutes to explain,
> if we sat at the same keyboard and wrote some Ada.
We could define "+" as follows:
Left parameter: covariant
Right parameter: covariant
Result: contravariant, class-wide (=polymorphic type)
So the profile will be:
function "+" (Left, Right : Real) return Real'Class;
Then when we derive Complex from Real, we have to override "+" three times:
function "+" (Left : Real; Right : Complex) return Real'Class;
-- This deals with 1.0 + (3.0, 1.0)
function "+" (Left : Complex; Right : Real) return Real'Class;
-- This deals with (3.0, 1.0) + 1.0
function "+" (Left, Right : Complex) return Real'Class;
-- This is for (3.0, 1.0) + (1.0, 0.0)
With this "+" Complex will be substitutable for Real. For example in the
program Sum:
function Sum_Three (X, Y, Z : Real'Class) return Real'Class is
begin
return X + Y + Z;
end Sum_Three;
>>> is that sensible...or even correct terminology.
>>>
>>> number Add(number x, number y)
>>> {
>>> return x + y;
>>> }
>>>
>>> in all context for real numbers...i.e, where + : R x R -> R goes to C x C->
>>> C
>>>
>>> void ClientAdd()
>>> {
>>> Real r1 = 1;
>>> Real r2 = 2;
>>>
>>> Real r3 = r1 + r2.
>>> }
>>>
>>> I can substiture complex for real (actually this is similar to the OP
>>> question really).
>>
>> Yes, if +, =, 1 and 2 are dispatching (covariant). Then Complex r1 = 1
>> dispatches to a correct "1" (1+0i), r3 = r1 + r2 dispatches to complex
>> addition and then complex assignment and everything is fine.
>
> So it does work with my example?
It could but you have to rewrite it to have substitution. There are the
following possibilities for ClientAdd to do so:
1. Make it a template with a type parameter
2. ClientAdd have to be a member of Real. Then it will dispatch according
to some actual parameter type.
3. ClientAdd have to be class-wide of Real. It works with all types derived
from Real, i.e. have a parameter of Real'Class type. In the body it will
dispatch according to the actual parameter type.
(1) is rather uninteresting, it is static polymorphism a-la cut-and-paste.
For (2) or (3) we need some parameter to pass into ClientAdd and so trigger
substitution.
>> But beware, it is not always possible to do. Consider:
>>
>> < : R x R -> Boolean
>>
>> We could not make it right, complex numbers are unordered!
>>
>> It is always so: you to gain something you have to lose something. That
>> kills LSP.
>
> in the example it works because;
>
> there is a homomorphism between M from R->C
> and another
> inverse M : image(M)->R ?
>
> so inverseM(M(x)) = x...forall x in R.
>
> or am I still barking up the wrong tree.
I think you are right. We found in C elements which "behave" exactly as
some other elements from R *in* the program ClientAdd(). But we will not be
able to (1) find such for all possible programs and to (2) ensure that it
will be the same homomorphism for all programs. (1)+(2) is IMO the essence
of LSP subtyping.
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
- Next message: frebe: "Re: What is an OODBMS?"
- Previous message: Vijay: "Re: Empty interface and polymorphism"
- 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"
- Reply: Robert C. Martin: "Re: Liskov Substitution Principle and Abstract Factories"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
