partial class

[Christopher Wright]

Julio César Carrascal Urquijo wrote:
> Hello Christopher,
> 
>> Model / view / presenter?
>> http://martinfowler.com/eaaDev/SupervisingPresenter.html
>> I'm not sure what you mean by "avoid several round trips over a slow
>> network" -- having one extra class won't force that. It's the
>> difference between your view generating a partial request and your
>> view generating a complete request (and perhaps submitting it at the
>> same time). You'd have the exact same approach with partial classes as
>> with multiple classes.
> 
> This section of the system is a rewrite of and older system where 
> multiple classes where used to send partial messages. I used this 
> pattern to aggregate messages in one SOAP envelop.
> 
> You are right that multiple classes doesn't imply multiple messages but 
> putting all calls on one class surely helps making sure those messages 
> are aggregated. The downside is of course the class grows pretty rapidly 
> but thats where partial classes come into play :D

Storing all the data in one class makes sure those messages are 
aggregated. The methods to manipulate that data can be in a second class 
if that's reasonable, and the methods to determine how to manipulate 
that class can be in a third.

> My point with the example is that Facade pattern benefits from "partial" 
> because the point of the pattern is to provide a coarse grained 
> interface to the client.

In this case, you can determine what the interface is -- the presenter 
or the view.

If you want to provide both a low level interface and a high level 
interface, inheritance is a reasonable facsimile of partial classes. 
Otherwise, I'd prefer MVP.