Michal Kleczek wrote:
On Tue, 2011-02-01 at 13:12 -0600, Gregg Wonderly wrote:
Digging through classes belonging to a service implementation that is
designed to be encapsulated/not your concern? Does that sound right? I gotta
say, it sounds horribly invasive, very hacky and speaks of an overly complex
solution as the result of treating symptoms, not problems.
Okay, I want to go through the problems that I was dealing with, the attributes
of the current mechanisms, and how I inserted points of control to manage these
issues.
First, let's look at the simple client mechanisms I wanted to have. I have a
desktop environment, which does lookup, and then shows treeviews of services
based on "machine"->"group"->Service Instance structure. The deployed services
contain Entry objects that provide values for these three name spaces. Since I
need to look at these, they can not be preferred by the service or I can't read
them. There may be a subclass that the client has used, and that can be
preferred no problem. There are some other items in the Entrys that I need too,
such as icons. Any of the Entry objects that I need access to, and any classes
which they are dependent on, and which are publicly visible classes/interfaces,
because of that attribute (public) can not be realistically preferred.
I think I'm with Dan here - looks to me like a misuse of LUS. I see it
as a more or less dumb bootstrap mechanism - designed for _lookup_ not
_browsing_ .
Wouldn't a ServiceBrowserService (or a ServiceIndexingService) be a
solution?
Michal
Can you give an example?
Peter.
