so, I have a class (foo) that has 3 methods that can be accessed by
1) UniqueID (assigned outside my control)
2) GUID (I don't like integers as key identifiers )
3) Name
would you
1) provide 3 methods to find this unique entity ,
method public foo DoSomethingUsingID(p_ID as int):
method public foo DoSomethingUsingGUID(p_GUID as char):
method public foo DoSomethingUsingName(p_Name as char):
2) provide 1 method
method public foo DoSomething(p_foo as foo):
/* I can use either :UniqueID, :GUID or :Name as I want here */
3) combine all 4 methods ?
First, I will just comment that you must have a very confusing name space since it seems like you have posted 100 different examples of a class named foo, presumably distinguished by the package name.
Second, one the surface, this looks like a classic situation for method overloading, but unfortunately you have two parameters which are strings. Figure out a way to make one of those a unique datatype and your problem is solved.
Third, I am disturbed by the implication that UniqueID and GUID are both unique identifiers of the same thing. Codd would not be pleased. If this is a case of you gluing everything together by GUID, but getting UniqueID from some external source so that you need to keep track of it, consider encapsulating the relationship so that you don't end up using UniqueID in your own interfaces and provide a lookup to get from one to the other in those contexts where you need to.
tamhas wrote:
First, I will just comment that you must have a very confusing name space since it seems like you have posted 100 different examples of a class named foo, presumably distinguished by the package name.
Second, one the surface, this looks like a classic situation for method overloading, but unfortunately you have two parameters which are strings. Figure out a way to make one of those a unique datatype and your problem is solved.
Third, I am disturbed by the implication that UniqueID and GUID are both unique identifiers of the same thing. Codd would not be pleased. If this is a case of you gluing everything together by GUID, but getting UniqueID from some external source so that you need to keep track of it, consider encapsulating the relationship so that you don't end up using UniqueID in your own interfaces and provide a lookup to get from one to the other in those contexts where you need to.
First: no, there's no confusing namespace, just using foo instead of the real class / method names so that nothing can get confused for the examples. ... guess I failed. I use "foo" to mean "don't read anything into the class , method or property name"
Second: I would agree, but I can't make one a unique reference. they both are.
Third: the uniqueID is part of a unique key (system:Uniqueid) [for sake of clarity, the uniqueID is only unique by system) that is generated by an external system. I use a GUID as a truly unique indentifier because I don't want other tables linking to this table with thousands of records with a foreign key of "SystemFoo:SomeID" . yuk.
My second options simply passed an instance of foo - how this "foo" is got could be left as an excercise to the developer, but I was considering adding helper methods to the class so that they don't have to.
My world revolves around making the API practical and easier to use, rather than theoretically correct.
Codd can go fish ...
First, it was a joke ...
Second, while they may mean slightly different things, the meanings overlap, so if you really, really need to hang on to both, encapsulate the use of one and only use the other to connect components in your system. Really, 3NF and the other rules weren't created just for some sense of arbitrary purity, they are actually sound rules for database (and object) design and ignoring them is likely to cause you trouble in the end.
first: yup. very droll. sorry I missed it
second: it's more cumbersome - the uniqueid is used to store a large binary file on the filesystem somewhere (and I *really* don't want to store this in the db), so I need to have access to the uniqueid from my object. External people only have access to this uniqueId as well.
third: yah, I was joking about Codd and fishing. If he were named Salmon, would that have made the joke a little more obvious ? ...
Re the second bit: if the purpose of that uniqueId is to locate the blog on the file system, why do you need a method to find your object by that ID?
Wouldn't by GUID and by name not be enough?
second bit: Normally I would agree with you. However, the uniqueid
also happens to be the name of a file sitting on a server, which
external systems / people can browse. So they need a way of getting
the record by using the uniqueid only
Actually, thinking about it, this also affects my legacy systems. At the moment, older tables are defined with a unique integerID . As we modernise the system, we are also adding a GUID field to each ta ble (so that records can be transported from test to live). So now, each of these tables have 2 unique identifiers as well. There is no way that I am going to go through the entire system to replace ID with GUID, so they have to live side by side.
Whilst overloading takes care of the find method, it still makes Codd very unhappy.
So they need a way of getting the record by using the uniqueid only
Got me convinced. As there seems to be a business requirement and I guess the use of an additional cross linking directory would be overkill
Whilst overloading takes care of the find method, it still makes Codd very unhappy.
Never seen happy fish anyway (outside toons)
I did get the Codd "joke" ... I was just being serious ...
Lookup seems the right answer to me. You are just going to create a mess if you keep both and propagate this everywhere.