Re: Interface complexity problem in game
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Mon, 26 Sep 2005 15:32:57 GMT
Responding to Guild...
This paragraph suggests that 'world' represents another, largely undefined subsystem. In that case it is a subsystem interface.
Using the GoF Facade pattern is a common way to implement subsystem interfaces. While that Facade is a single class with a large number
of interface methods, it does not implement the functionality. It is simply a buffer class that re-dispatches the messages to the objects that implement the subsystem. So in that case a large number of
methods is acceptable. In fact, it is highly desirable because it
hides the implementation of the subsystem.
This is exactly what I am doing. I would be crazy to try to define something that I know will be vastly complicated without breaking it up into a large number of objects. Therefore, I will continue with confidence and much appreciation!
OK, but a couple of caveats. Facades should be simple. That is, they should not contain problem semantics in their implementations; they exist purely as a decoupling agent to hide detailed implementations. Ideally they simple redirect a message. However, that segues to the second caveat...
Subsystem interfaces should be pure data transfer interfaces (e.g., that's why event-based interfaces are popular for things like GUIs and RAD IDEs). That is, one just has {message id, data packet} where the data packet contains by-value data. The receiver uses the "message id" to determine how it should respond. In a Facade pattern the "message id" essentially becomes the Facade method name (e.g., the "doSomething" in your original post).
Note that in event-based processing one needs only one processEvent (event id, <data packet>) method in the interface. This is fundamentally equivalent to a bunch of processAnEvent (<data packet>) methods, which is why lots of methods in a Facade interface is not a problem.
The real key to decoupling, though, is that only by-value data is passed. The data packet may be implemented as an object (this is what DAO is about) but it exists only for the communication. That is, one does not pass objects across the subsystem boundary that are part of the subsystem implementation because that exposes the subsystem implementation.
Such interfaces come at the price of encode/decode of the data packet on each side. However, that will be more than offset by improved robustness due to the decoupling of the implementations (i.e., all each side needs to do is properly map the "message id" and the data packet in its own terms). Thus changes are much more likely to be restricted to one side because the data the other subsystem needs is unlikely to change (i.e., just the way it is selected for the encode is changed). (Data tends to be more stable than behavior when requirements change.)
--
************* There is nothing wrong with me that could not be cured by a capful of Drano.
H. S. Lahman hsl@xxxxxxxxxxxxxxxxx Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
.
- Follow-Ups:
- Re: Interface complexity problem in game
- From: Brendan Guild
- Re: Interface complexity problem in game
- References:
- Interface complexity problem in game
- From: Brendan Guild
- Re: Interface complexity problem in game
- From: H. S. Lahman
- Re: Interface complexity problem in game
- From: Brendan Guild
- Interface complexity problem in game
- Prev by Date: Re: Program to an Interface not an implemetation
- Next by Date: Re: Question about <The Deadline: A Novel About Project Management >
- Previous by thread: Re: Interface complexity problem in game
- Next by thread: Re: Interface complexity problem in game
- Index(es):
Relevant Pages
|
