Originally posted by Ilja Preuss:
Hell, I even wouldn't know how to design without "seeing the accompanied code in my head".
Originally posted by Ilja Preuss:
The only real semantic difference [from asociation] is that there is no cycle allowed in aggregation.
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.
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.
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
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 -
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.
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
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.
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.
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.
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
Originally posted by Marilyn de Queiroz:
As far as I know all cookies are saved in plain text on the client side.
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.
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."
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, ...
Originally posted by Jim Yingst:
I believe the main natural source is iron-containing ores.
.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.
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)
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"
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"
Originally posted by Mapraputa Is:
there is no "Don Liu" in dictionary either, do we need one here?![]()
Originally posted by Mapraputa Is:
there is no "Don Liu" in dictionary either, do we need one here?![]()
Originally posted by Map:
So you think "programmer" propagates programs by having sex with them???