Show 15 posts from this thread on one page
Objects by Design Forums (http://forums.objectsbydesign.com/index.php)
- UML Certification Review Questions (http://forums.objectsbydesign.com/forumdisplay.php?forumid=18)
-- name collision (http://forums.objectsbydesign.com/showthread.php?threadid=219)
Which of the following is the BEST strategy for resolving class name collisions that occur during OO analysis?
a)Allow each team member to choose names for only those classes which they will build.
b)Create a class for each domain name, passing on requests to the one class that implements the behavior for all of them to share.
c)Discover unique names for different concepts that are referred to by the same term.
d)Put the classes into different packages so that the fully qualified class names are different.
I believe answer is c. Any other explanations?
I would think the answer is d.
For example, Consider the University Registration System. There could be several use cases - a student registers for a class and prints the class schedule, a teacher views the classes that the teacher will be teaching and prints the class roster. Each of these use cases has a "print" functionality. It would be difficult to come up with unique names for a same print concept. Instead, we could have a student package with a print class that would specifically handle the student's printing needs and a teacher package with a print class that would handle the teacher's printing needs.
I am new to the field of UML, and could be totally off.
OOPS! First of all, I think, "print" is not a concept. It is action.
The answer should be (c).
Let's examine the example(say case-study) that mentioned. Here, in the first step-
you can derive the following concepts like this-
Write down the description of each concept and name it. Add attributes and associations between them.
Take the specification perspective and add interfaces like
Create a class or derive a new one which implements one or more of the above interfaces and implement them.
The above question can be simulated like this-
Think of graduation courses, regular and part-time. Then a Student class will have same name when considering a regular course or part-time course. In that case, modify the Student class's name to RegularStudent and PartTimeStudent.
Any one have better explanation?
I agree the answer should be (c).
Another example is say you have the following classes on the conceptual level, Checking Account, Savings Account or Money Market Account, which are all referring to a type<<interface>> of Account, but the names are more meaningfull.
Also look at the java.io package, Reader, BufferedReader, CharArrayReader etc.
Looks like my example instead of proving my point took the discussion on a tangent.
My point is this:
Option "c" in my opinion, eliminates one of the benefits of OO - that is, being able to provide things with useful names that make sense in a specific context, even if they aren't completely unique - that is what packages are for. We see this in method names with polymorphism - adding a number doesn't mean the same as adding to a date. The examples that were presented by smsreedar and cejac deal with specialization, in which case it makes sense to have unique names - but we are not talking about specialization here.
Hmm.. resolving class name collissions during OO analysis!
I think the key is during OO Analysis. During analysis we are debating different concepts of the domain and trying to understand it. If there are two checking accounts offered by the bank (say one that offers interest and the other that doesn't), it would be convenient to have unique names for the domain concepts (in this case checking accounts). This helps unambiguous communication among the stake holders. In this context, discovering unique names for the concepts is the best strategy.
During design and implementation, the classes could be grouped in different packages and may be referred with their fully qualified names.
Hope that helps.
Answer should be "c"
Don't choose 'd'... it is a clever trap. Look at the 'reasons for grouping classes into a package' in the Larman notes on this site (section 3 architecture).... resolving naming conflicts is not on this list.... and if you think about is not a very good reason for grouping classes in one or another package... choose a different name.
As I understand, given a namespace and a name, a particular element in a namespace can be found. The top level namespaces are packages.
Packages only aid in a logical grouping and it is possible that you have a name clash within that logical grouping (during analysis). In such a situation, one would look at coming up with alternative names (unique) rather than moving the class to an other package - to overcome the name conflict problem.
So I would route for option 'C'.
|All times are GMT. The time now is 02:22 PM.||
Show 15 posts from this thread on one page
Powered by: vBulletin Version 2.3.5
Copyright © Jelsoft Enterprises Limited 2000 - 2018.
Copyright ©1999-2005, Objects by Design, Inc.