Guennadiy VANIN

Ranch Hand
+ Follow
since Aug 30, 2001
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Guennadiy VANIN

"in the style sheet you (frank? paul?)
I thought that it is extracted from the Bible. I would like to know the absolute truth: who are the authors?
"hungarian notation violates OO"
May I ... ? Thanks anyway.
I have read, or I make up, as usual, that setters and getters violate OO
Reasoning:
1)"get"/"set" paradigm is MS's contribution to OOP.
It is considered rude to get/set something directly. If you need something to be done, then give that job to that object without any extortion for your own job.
2) Objects are to communicate only through publicly determined/exposed interfaces.
21 years ago
Everybody finished? May I?

Originally posted by Ilja Preuss:
Hell, I even wouldn't know how to design without "seeing the accompanied code in my head".


I rather miss a lot. I always thought that architect or programmer-analyst designs, writes in words, defend those descriptions to get financing and after getting money, hire someone to write the corresponding code.

Originally posted by Ilja Preuss:
The only real semantic difference [from asociation] is that there is no cycle allowed in aggregation.


I am getting to this phrase because I see it over and over again. I cannot see how it illustrates any semantics because I even cannot recall any, even single example of, cyclic implementation of association. Does this phrase mean that the only purpose of aggregation is to exclude the potential threat of cycle?! I may give counterexample: any object is simultaneously the whole and the part of itself.

Originally posted by Vikrama Sanjeeva:
I dont think that the method getAccountType is placed in AccountType class and Account class send message to AccountType for asking account type.Rather this information is provided as soon as Account instance is created, possibly via Account's constructor.


Account instance might not be created at all as far as semantically Account is just abstract notion or even an interface to concrete SavingsAccount and CurrentAccount. It is overtypical model example in all UML compliant illustrations.
It is used for illustration of a couple of dozens of patterns. For ex., Change an Object's Class at Run-Time (State Pattern)
http://ootips.org/state-pattern.html,

Originally posted by Frank Carver:
It might even be that Account doesn't actually need to know about AccountType at all - maybe they would be better aggregated together into another class.


What I wanted to write. I am bad in patterns but it seems to me that it is called Visitor Pattern?

Originally posted by Piyush Daiya:
As u have mentioned Pradeep, u want account type in account class i.e account type is attribute of account class.Hence the relationship you have to show is association.
Inheritance is type of generalisation relationship.(A Generalisation relationship is relationship among classes where one class shares the structure and/or behaviour of one or more classes).
Since, you havent mentioned anything about sharing structure or anything between Account or AccountType, inheritance is not the relationship between the classes.
Association relationships can be of Aggregation and Composition types.
HTH,


Originally posted by Ilja Preuss:
Oh, ok – if it is a given that Account holds a reference to AccountType, it


Relationship doesn't mean inevitably association PERIOD
Association doesn't mean Aggregation or Composition PERIOD
Association doesn't mean having necessarily references THREE PERIODS

Fowler, Martin. UML distilled: a brief guide to the standard object modeling language / Martin Fowler with Kendall Scott. - 2nd ed., 2000, Addison Wesley
p.52
Associations represent relationships between instances of classes...
p.54
An association also implies responsibility for updating the relationship. ...
These responsibilities do not apply to data structure, however... I cannot and should not be able to tell whether the Order [Vanin: read "one" instead of "Order"] class contains a pointer to Customer [Vanin: read "another class" instead of "Customer"], or whether the Order class fulfils its responsibility by executing some selection code that asks each Customer whether it refers to given Order.
p.57
"So a parameter reference, or the creation of an object, does not imply an association, you model those with dependencies (see Chapters 6 and 7)"


Originally posted by Ilja Preuss:
Well, all [composition] it adds over aggregation is lifetime responsibility -


I do not agree because association already has life-time responsibility.

Fowler, Martin. UML distilled: a brief guide to the standard object modeling language / Martin Fowler with Kendall Scott. - 2nd ed., 2000, Addison Wesley
p.57
An association represents a permanent link between two objects [Vanin's comment: I would have said between object's populations]. That is, the link exists during the whole lives of the objects, although the instances that are connected may change over time (or, in optional association, be empty). So a parameter reference, or the creation of an object, does not imply an association, you model those with dependencies (see Chapters 6 and 7)"


Originally posted by Ilja Preuss:
And I think Account somehow probably would want to send messages to AccountType.


I couldn't even understood Account as a concrete entity... Account could have been an abstract superclass to concrete classes CurrentAccount and SavingsAccount. But I never use/honor inheritance from political convictions and also because:

Originally posted in
Mark Grand, Patterns in Java: a catalog of reusable design patterns illustrated with UML, Volume 1. - 2nd ed., 1999, John Wiley & Sons
p.56
"Delegation is more general purpose than inheritance. Any extension to a class that can be accomplished by inheritance can also be accomplished by delegation "
"Some inappropriate uses of inheritance are so common that they can be classified as antippaterns. In particular, subclassing utility classes and using inheritance to model roles are common design flaws"



Originally posted by pradeep anandan:
As in RDBMS we have 2 different tables one for Acccount type and other Account and have a foreign key relationship
will the same is applied in OOPS where The rate of interest differs with the account type


To me this phrase is broken both lexically and semantically but I would tell that foreign-key relationship needs in almost cases Association class.

Originally posted by Ilja Preuss:
And don't get fooled into the thinking that you need to somehow "finish" analyzing before you may start designing or even should have finished your design before you start coding.


To me analysis is disintegration of problem domain to atomic elements and notions. Design is synthesis from those bricks. I do not know anyone who builds a building using floors, corners, rooms of the previous building...
Yeap Ilja,
You are right.Analysis and Design are to be done iteratively.
Piyush

I agree. But this doesn't mean using unfinished/incomplete analysis results at each stage!
BTW the literature (books, articles) on OOAD, patterns are full of discussion of, first of all, Account-SavingsAccount, CurrentAccount models, relationships, patterns, antipatterns. I am surprised that these notions happened to be so mysterious /unspecified. You cannot find a single book on patterns, CASE, OOAD without bank accounts model!
But relations may be quiet complex. For ex., there could be a contract that if the CurrentAccount balance drops below certain minimum, then money automatically is back-up-ed from the SavingsAccount (excellent illustration of pre-, post-conditions and invariants).
If the total amount of money (dinheiro, dengi, dollari, euros) disappear/vanishes then accounts change the state to frozen/closed, with quite a different character and behaviour (who may and may not access it, use credit card,
etc).
This is the perfect case of illustration of 2 dozens of patterns.
Since Java doesn't have (?) dynamic types (as well as other mappings to UML notions) then the models and patterns would depend on language orientation, etc.

Originally posted by Peter den Haan:
guess this is a religious issue. I, too, have something against prefixes, suffixes and other decorations -- as Kyle says, if you need them your method or class is probably too large or complicated.


Having big classes is a performance issue (i.e. small classes deteriorate significantly performance).
Also working in big projects you do not have control over style of the others especially over huge bulk of the code created years ago. At my recebt jobs, I had classes code with thousands lines of code which I needed to use or just modify by one line. And what, due to small need, I should refractor huge existing for years applications? Either take religious for granted or be martyr.
Thanks a lot, Ashok.
I am not lazy in googling but I had rather different approach and restricted resources for experimenting
21 years ago
Excellent explanations about no need of inheritance.
Can anybody explain me how "Inheritance breaks encapsulation"?

Originally posted by Desai Sandeep:
Originally posted by Jean Huang:
At first I thought the answer should be "C", but after I saw a post said "I think for Q1 the answer should be D .Please refer Craig Larman, Applying UML and Patterns,Section 39.9.1,Page448.", I got confused. Which one you think is right?
This was my post, that you are refering to.I think you were correct earlier.


Y-e-e-e-h, I read Craig's 2nd ed. of book, and it ends in chapter 38... What was the title of chapter and section?

Originally posted by Marilyn de Queiroz:
I would like to see the "rules" (for ex., the time period of postings to compete for giveaways) that, I dunno why is known but persistently not fixed/written.

Book Giveaway Information Page


That page informs about closing on Friday while closing happens on Thursday

Originally posted by Marilyn de Queiroz:
As far as I know all cookies are saved in plain text on the client side.


This is not correct. Just observe the functioning of any buy-on-line site.
Even if it had been so, it could have been easily partly remedied by setting Expiration Time of cookies. I wrote it long time ago. The inconveniencies are huge in comparison with the half-minute work.
Instead I was foolied in dozens of posts (hours of writing) that this site is passing to Jive, then everything is OK/no problem with UBB, my threads were closed or transferred, then finally in another thread I had read that Jive is in the dead already waters for months.
There is a lot of time for misleading and mockering posts, making others fools, pursuing them to distort, delete, truncate others' inoccuous posts!

Originally posted by Marilyn de Queiroz:

Some individual forums have FAQ's, but so far nobody has had time to create an FAQ for the whole ranch. Notice that even most of the forums do not yet have FAQs, only a couple of them have an FAQ.


Anybody asked? I have not seen. I am more than sure there are lot of volunteers and time amongst 50000 members.
The problem is that this site is more oriented for moderators being meaningless (i.e. in MD) than opened.
I had time and desire BEFORE, but not now, not for this site where I was treated like annoying fly and/or idiot to be ousted.
I was told that I am the only case. Nope, I know others that wanted to help and had gone.
Then I was misinformed (or informed in a distorted way) who and what can do in Javaranch
[ January 28, 2003: Message edited by: Guennadiy VANIN ]
21 years ago

Originally posted by Thomas Paul:
Jim, I'm not aware of any posts that were deleted. Some threads were closed but that was the limit.


Her is the Private message sent to me by Thomas Paul in 23 of January, 2003
"Please don't post the same message in multiple threads."


All my 4-5 posts , namely with the following text of post: "www.uksociety.org",
promptly disappeared. They were in different and appropriate for discussions contexts
Isn't it about deleting all without leaving a single one?
Where is the written rule that prohibits post more than once the same, "phrase" in different contexts?
Where is the rule that, therefore, all posts are to be deleted? without leaving a single exception exception
If you still are not aware I may repeat (already more than tenth time): my posts are continuously hijacked, distorted, deleted by moderators and I am treated like a jerk that invent things.
My personality, and not my subjects, are attacked, my name is distorted, without even reasons, and it is "moderated" in the sense of organization/support and not moderating by moderators.
This lasts already more than a year.
I pretend to know exact notion what who are moderators and what moderators are for? For being meaningless, making buddies here?
[ January 28, 2003: Message edited by: Guennadiy VANIN ]
21 years ago

Originally posted by Jim Yingst:
It was also possible to create manmade magnets without electricity. Take an iron rod, point it north, and hit it hard with a hammer along the axis. The vibrations temporarily free up some of the atoms, a little - and they have an opportunity to reorient themselves a bit, ...


What is being shown at Primary School and then at high one being explained. McGyver used to save himself making magnets on-the-fly in that way.

Originally posted by Jim Yingst:
I believe the main natural source is iron-containing ores.


They are called magnetic anomalies. Magnets are quite crazy in those places as well as over any big metal deposits even not natural.
I recall that electromagnetic cranes do magnet metals only as far as there is electricity. The reason is very simple you cannot have strong (and controllable) magnetic field from "natural" magnets.
21 years ago

Originally posted by Roshan :
but foo in A is declared protected then B will break because you cannot override foo in B with more restrictive visibility than in A.

.
It is just the compilation error. After this either you remain with a previously compiled application or you correct the eror. Nobody is hurt.
Broken code does not illustrate broken encapsulation.
Ilja Preuss: Ibid. Broken code does not illustrate, at least to me, broken encapsulation.

Originally posted by Junilu Lacar:
Here's the paper by Alan Snyder that is often referenced: http://www.cs.colorado.edu/~diwan/class-papers/snyder.pdf
Also, Joshua Bloch discusses concrete Java examples in his book "Effective Java Programming Language Guide" (Items 14 & 15)


Snyder's article dates to 1986 and completely irrelevant to Java. It states that client of class may access instance variables only through methods (not the case in Java, cf. public) and encapsulation is broken, because designer can't prevent inheritance of instance variables and/or methods (again wrong for Java. Cf. private).

I haven't Joshua Bloch's book.

I do not see how the encapsulation may be broken through inheritance.
Let me cite more relevant to Java:

Originally posted in
Mark Grand, Patterns in Java: a catalog of reusable design patterns illustrated with UML, Volume 1. - 2nd ed., 1999, John Wiley & Sons
p.55 "There is no way effectively hide methods or variables that are inherited from a superclass"


Agree. But it is because, designer of superclass, did not bother to hide them by using private. It cannot be judged as "break of encapsulation" because the data in supercalss was not encapsulated in first place.

Originally posted in
Mark Grand, Patterns in Java: a catalog of reusable design patterns illustrated with UML, Volume 1. - 2nd ed., 1999, John Wiley & Sons
"An even more serious problem is that client classes can call the public methods of the utility superclass, which defeats its encapsulation"



"Defeats"? Where? It was NOT encapsulated in supercalss, because it had public modifier and could be reachable in superclass outside of inheritance.
I still cannot understand. Protected or public members (in supercalss) are accessible by objects of another classes and therefore are not encapsulated. There is no sense in claiming the break of absent encapsulation.

Now if the member is private and therefore encapsulated, it is not available through subclass/inheritance. Where is the break?
OK, after writing this I found
https://coderanch.com/t/96837/patterns/Composition-versus-Inheritance
that expalined me what I known, i.e. that inheritance is not good but I really had never used it before.
Still without explanation how inheritance breaks encapsulation

Originally posted by Mapraputa Is:
there is no "Don Liu" in dictionary either, do we need one here?


According to my beloved "Harrap's Mini Pocket English Dictionary. 125,000 words and meanings"don [don] 1.n. university teacher; 2. v. (donned) to put on (a pieche of clothing). You can Don after Mapper
21 years ago

Originally posted by Mapraputa Is:
there is no "Don Liu" in dictionary either, do we need one here?


According to my beloved "Harrap's Mini Pocket English Dictionary. 125,000 words and meanings"don [don] 1.n. university teacher; 2. v. (donned) to put on (a pieche of clothing). You can Don after Mapper
21 years ago

Originally posted by Map:
So you think "programmer" propagates programs by having sex with them???


Map and Paul,
On graduation from university, alongside with a civil degree I was simultaneously assigned the rank of military engineer officer. For that occasion, a medical commission examined me. A psychiatrist, amongst other doctors, asked me a question: "What is the difference between a bird and an airplane?". I was then young, arrogant and considered me yet quite sane but till now I recall with a shame my first 2 (incorrect) answers.
I am curious if you are able to give the main correct answer to this question?
21 years ago