Re: Liskov Substitution Principle and Abstract Factories
From: Dmitry A. Kazakov (mailbox_at_dmitry-kazakov.de)
Date: 01/17/05
- Next message: Shayne Wissler: "Re: Encapsulation vs separation of concerns"
- Previous message: AndyW: "Re: how many bugs do you find and correct during TDD?"
- 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: Mon, 17 Jan 2005 21:54:00 +0100
On Mon, 17 Jan 2005 14:21:24 -0000, Mark Nicholls wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1vjlzggk7b44f$.5mjeps9qwold.dlg@40tude.net...
>> 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!
>
> OK, but that's not my definition...or OO, I need 'objects', now in a sense
> you have inserted another layer of indirection between an object, and the
> functions that may be construed as 'methods'.....that's fine....I don't
> believe I have seen this anywhere else...i.e. not in Rumbaugh, Booch, Meyer,
> GoF....and others....its not a criticism.
I just see no other way to deal with all types uniformly. Why Boolean
should be no object?
>>> 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?
>
> yep
>
> quite so.
>
> is the set of primes that differ by two bounded?
>
> I cannot answer you except to say, given a set of assumptions we can say it
> is probably 99.999% true....this has been done, by mathematicians, in number
> theory books.
>
> i.e.
> is the set of primes that differ by two bounded?
>
> answer....I don't know, but I'm 99.999% sure it isn't.
This is a statement about you, not about prime numbers. That's the point.
Today you might be 99.999% sure, next day 2%. And BTW, uncertainty you are
talking about is not random. It is fuzzy. It would be random if being asked
you would answer either yes or no. That's not the case.
>>> 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.
> If I knew the exact position of every single particle in the world, could I
> not, exactly predict the weather........(OK, there's a lot of problems with
> this statement, but as a thought experiment).
That's mechanics.
> But we don't, so we take a statiscal approach i.e.
>
> given I don't know the exact position, I can make all sorts of dubious
> assumptions that makes their positions/temp/humity into a statistical
> observation.
Maybe the mechanical view is comprehensive. But that is no matter. When you
model weather you are working within a statistical framework, i.e. with
thermodynamics. We do not consider each particle, we deal with sets of
them. On the contrary when we write programs we consider each statement,
each declaration etc. We do not treat them as random occurrences. It is
questionable is something reasonable as thermodynamics could be deduced f
we would.
1. Our programs are too small for that (comparing the number of states of a
program and 1 cubic meter of gas)
2. They are very instable. Small local changes lead to great difference in
behavior.
So I do not thing that statistical approach might work here.
>>> 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.
>
> stochastic.....implies there is no link between Sn and Sn+1.....it does not
> mean it is not predictable, in some statistical manner.....e.g. stocastic
> random walks.
>
> i.e.
>
> P(Sn+1=4 \ Sn = i) = P(Sn+1=4) = 1/4
Right, you don't have Sn=x you have Pr(Sn=x). It renders anything to
probability. You will never be able to make a firm prediction.
> i.e. it is stochastic (i.e. it's conditional probability doesn't
> change......given a fixed statistical model).
>
> but it still submits to probability.
>
> i.e.. you make a set of observations, and build a model.
>
> given the model, each subsequent observation is assumed to be independent of
> any previous one.......given the model......but you need to run the
> experiments to create the model.......and you can statistically query the
> model via a hypothesis test......i.e. how many observations do I need to
> make before I believe/disbelieve that the model is correct and there are no
> other factors influencing Sn.
No. Actually it is: how many observations you need to make before the
probability of an error will be lover than epsilon. There is no way out.
>> 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 do not know the concrete result,
>> but you know that it will be the same as yesterday.
>
> for a specific set of input { In }, we know that the output will be the same
> tomorrow....assuming we haven't missed one (e.g. time).
>
> We can make assumptions (based on observation about the nature of
> programming teams), a team that consistently produces working code will
> generally produce better results than a team that doesn't......that is a
> statistical observation....not logical proof....but an indicator.
Yes, psychotherapy...
>> 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.
>
> I don't see the point....so what?
>
> I can assertain the probability of a lion entering the a specific cage, by
> doing lots of experiments and observing how long it takes on average for the
> lion to enter, and then when you say
> "how long will it take the lion to enter on average"........(or how long
> will it take before the program goes wrong).
Lion's behavior is random. Program's one is not. You have to have some team
changing the program. This would make the thing random. The team, not the
program. There is no magic in a program, it comes only with a process which
involves people. You can use statistics to judge people, not programs. So a
careful statement will be kind of:
Pr (Team X will make error Y performing operation Z | Coffee machine works
& Managers are on vacations & ...)
Bayes knows how to get from that:
Pr (P has bug | It was developed by team X)
>> 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.
>
> after observation, yes....before observation you either know nothing, or can
> 'guess' on the basis of a model.
>
> For example..which are the best lottery numbers to pick?
>
> surely they are all the same?
>
> wrong.
>
> some numbers are picked more than others (by the people guessing), so pick
> some numbers that other people don't and if you win, your expected win is
> greater than picking common, ones....i.e. the assumpton that people pick
> numbers at random is wrong.
[ But numbers are still same. You just changed the goal function.]
> We could do the same experiment with you and the 1 to 100 game, we would
> probably find you pick low numbers more often than big ones.......i.e. I
> suspect 1 will come up more often than 73........the number is random
> (before the observation) and not completely evenly
> distrubuted......programmers are probably similarly predictable, and so is
> their software.
I do not object that one could consider results of a team of developers as
a random variable. 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.
> again we cannot equate logic with probabiltiy.
>
> p(program works \ good programmer) > p(program works \ bad programmer)
The same program? In the statement above programs are two different
programs. Then I do not believe that the confidence factor p() above is
probability. People tend to make same errors over and over again. Should a
bad programmer implement the same problem 10 times the results will not
form nice Gauss distribution, we know it too well.
> If you are correct the above statement is wrong.....
It isn't wrong, it is just unclear what it formally means. It would be very
difficult, if possible to formalize it.
>> 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! (:-))
>
> People are not random code generators though.
>
> Even if they are we could probably make some assertions.
>
> e.g.
>
> x member {1....10}
>
> S=x*x
>
> whats the expected value of S? or even x?
>
> to say that they are random (evenly distributed) is a highly powerful
> statement, upon which we can make highly poweful predictions.
If you know the outcomes {1..10}. As I said it is difficult to present a
set of outcomes for a program P. Even more difficult is to judge about its
distribution.
>> 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!
>
> I don't follow the last bit.
People do not write programs randomly. We have agreed on that.
>> 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. ]
>
> OK....not bijective isomorphism surely?
Bijective!
> i.e. I can substiture complex for real
You cannot in + : R x R -> R. But you can in Read : File -> R
>.....but not real for complex?
You can in + : C x C -> C. But you cannot in Read : File -> C.
> because there exists isomorphism from real to complex....but not vice verca?
To make all possible substitutions work you need a bijection. So in the
most general case you need R->C and C->R. That is the problem.
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
- Next message: Shayne Wissler: "Re: Encapsulation vs separation of concerns"
- Previous message: AndyW: "Re: how many bugs do you find and correct during TDD?"
- 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
|
