They will use the information you provide to select people from their
database, based upon the details of the roles you filled as described
on your CV. They will use the information you provided about your pay
rate to maximise their margin by selecting the cheapest person
available to them for the role. This is not necessarily the best
person from the end-users' point of view, but that will not be allowed
to affect the decision.
What you will have done for them is all of their marketing work. What
they will do for you is zip.
Much better to anonymise your skills profile wrt previous clients (you
can always provide a second de-anonymised version for bona-fide
end-users, in the rare event they ask for one). You should contact any
managers / mates at previous workplaces regularly (3 - 6 monthly) in
order to find out what jobs are going and ensure that you get them not
some fly-by-night cowboy who happens to ask the lowest price. It is
your responsibility to your previous client, as much as it is to
yourself, to do this since otherwise they might end up with a less
satisfactory person in the role. And think how bad that would be for
their project ?
Your responsibilities are clear here IMHO : never discuss rates with
an agent prior to interview with the client and never tell an agent the
name of a previous client.
Re: Abstract public member variales? ... I can easily write the client without the burden of knowing how to make good moves, I will merely pass off that burden and make it a responsibility of the entity. ... My point is that problem space abstraction will lead to a quite different allocation of responsibilities. ... Apropos of the current context, I would also argue that looking at each of these individual tasks closely enough to identify individual requirements will make the lack of cohesion and logical indivisibility of your description of Entity.move more clear. ... (comp.object)
Re: Abstract public member variales? ... I can easily write the client without the burden ... You are creating preconditions by using the peer-to-peer design.... I don't think defining the requirements on a responsibility has anything to do with peer-to-peer access. ... But the level of abstraction for doing that is determined by the level of abstraction of the subsystem. ... (comp.object)
Re: Abstract public member variales? ... compared to even the slightest modification to the client.... For that reason I regard language-based information hiding mechanisms as more of a message to future maintainers that says, "I had a reason for restricting access in this context.... What knowledge the behavior needs is driven by what the behavior does, which is defined by that behavior's responsibility specification.... If I change the property of a gnome's height from 4 feet tall to ... (comp.object)
Re: delegation vs. inheritance ... I intended not to describe implementation inheritance but specification ... interactions involving superclass instances were modeled. ...responsibility is defined in one and only one place: ... the superclass responsibility correctly for the client context.... (comp.object)
Re: Opinions on the Law Of Demeter ... It seems to me LoD is about determining what ...>>Client is collaborating with A directly by accessing A's Mproperty. ...responsibility so Client needs to talk directly to it. ... By keeping relationship navigation to a minimum, ... (comp.object)
