Re: [UML Forum] I need to ask about the object class, but it's a bad practice. Alternatives for this case?

[H. S. Lahman]

Responding to GaL...

Hi! I'm having trouble extending an application. It is an attendance record system. Currently each employee records attendance by a card that has a QR code. Now they want to add fingerprint recognition, and there was no problem until they asked for two forms of identification must coexist in the system. Thus, the system must be able to sense QRs of the employee, but also his fingerprint.

(See Ejemplo.jpg)

Note that your diagram is not a Strategy pattern because the subclasses have different behaviors. So trying to access them polymorphically through the superclass is a no-no. That's the real reason you have a problem by needing to test the class.

The relationship from [Employee] to [IdentificationStrategy] has to be instantiated to the correct subclass for the context. However, if an Employee can be identified both ways, then both subclasses are correct and you have a conundrum if the type of identification is in the IdentificationStrategy because you don't know which one to navigate to.

From your description, some Client object is going to want to know about an Employee's identification. (Probably two different clients whose context is interested in a particular form of identification.) I don't see a need for a Strategy pattern at all. The Qrid identity seems to be handled as a simply attribute, which could be owned directly by [Employee]. You could do the same thing with a fingerprint, using an ADT. The behaviors in the subclasses seem to by just smart getters. So I would just put everything in [Employee].

I could see separate classes if there was something complicated about behaviors that processed identity data (e.g., matching fingerprints). But then the identities themselves would be in [Employee] and the Client that wanted one of those behaviors for its context would just navigate directly the the right subclass rather that through the superclass. (The subclass would go get the Employee's identifier of the type it needed). Note that this doesn't require a generalization (though it might be aesthetically pleasing); they are just two classes with particular behaviors and [Employee] has a relationship to both.

The way to fix it in QrIdStrategy is:

if (this == isKindOf (QrIdStrategy))
    if (this.getEmployeeId () == id.getEmployeeId ())
       return true;

return false;
 

But I understand that asking about the class of an object is a bad practice and don't want to do that. How can I fix it?

I agree with Wright. The subclass knows who it is already and doesn't need to test. Whoever instantiates the relationship to the superclass knows which one to connect up. You are painted into the corner of testing the class because you are accessing through the superclass, but it is not polymorphic access because the subclasses do not implement a single set of superclass responsibilities differently. The subclass behaviors are unique to the subclass, so the Client needs to navigate directly to them for its particular context.

Forget the Visitor pattern. You encounter a situation that really needs it about once every four employer. IOW, there is almost always be a better way.

-- 
Life is the only flaw in an otherwise perfect nonexistence
   -- Schopenhauer

Imagine how much more difficult physics would be if electrons had feelings
   -- Richard Feynman

Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
software book: Model Based Development, Addison-Wesley, 2011
geology book: The Evolution and Utilization of Marine Resources, MIT Press, 1972