== Don't Pull & Push at Once! ==

== Don't Pull & Push at Once! ==

The thing to remember is that (unless there are [[ImpossibleThreading|threading concerns]]), it is always possible to simulate the '''push''' approach with the '''pull''' one. E.g. it makes no sense to design an [[API]] that supports both - prefer the '''pull''' approach as the more flexible one. One can always turn push into pull:

The thing to remember is that (unless there are [[ImpossibleThreading|threading concerns]]), it is always possible to simulate the '''push''' approach with the '''pull''' one. E.g. it makes no sense to design an [[API]] that supports both - prefer the '''pull''' approach as the more flexible one. Your [[API]] users can always turn push into pull themselves:

<source lang="java">

<source lang="java">

}

}

</source>

</source>

This has some benefits (and it can even be improved to work without the '''registerTranslation''' method with [[Lookup]] based registration or even more with [[AnnotationProcessor]]s) over the '''push''' version. One doesn't have to load languages until they are really needed. Also one can translate unknown words - if the word to translate is in plural, it is the language implementation can make additional adjustments and convert it to singular form, translate it and then (in the target language) translate it back to plural. Or one can translate even words that don't make sense - by looking up the closest alternative.

This has some benefits (and it can even be improved to work without the '''registerTranslation''' method with [[Lookup]] based registration or even more with [[AnnotationProcessor]]s) over the '''push''' version. One doesn't have to load languages until they are really needed. Also one can translate unknown words - if the word to translate is in plural, it is the translation implementation that can make additional adjustments and convert it to singular form, translate it and then (in the target language) translate it back to plural. Or one can translate even words that don't make sense - by looking up the closest alternative.

This is the value of the '''pull'''-approach - one gets a callback and can adjust to it when needed.

This is the value of the '''pull'''-approach - one gets a callback and can adjust to it when needed.

== Pull like Approach ==

== Pull like Approach ==

Why register everything at the beginning? It is not even clear the registered translation will really be needed. In such open-ended system, it is very likely better to try a '''pull'''-like pattern:

Why register everything at the beginning? It is not even clear the registered translation will really be needed. In such open-ended system, it is very likely better to apply a '''pull'''-like pattern:

<source lang="java">

<source lang="java">

public interface Translate {

public interface Translate {

</source>

</source>

in a system of such kind you require all translation [[module]]s (it probably makes sense to assume the translations are developed independently, right?) to eagerly - e.g. as early as possible - register themselves into the system and provide necessary details. From which language they translate words, to which language and what is the vocabulary they can handle. This is probably too premature - better to ask when needed.

in a system of such kind you require all translation [[module]]s (it probably makes sense to assume the translations are developed independently, right?) to eagerly - e.g. as early as possible - register themselves into the system and provide necessary details. From which language they translate words, to which language and what is the vocabulary they can handle. This is probably too premature - better to delay such query and only ask when really needed.

== Pull like Approach ==

== Pull like Approach ==

The [[Extreme Advice Considered Harmful]] chapter of [[TheAPIBook]] talks about symmetry. It describes how harmful seeking for full symmetry at all costs can be. The chapter argues that there often isn't a need for both [[GettersAndSetters]], that in many cases just getters in an [[API]] are enough. Similar example can be given for [[PullXorPush|pull vs. push]] in [[API]]s - it is unlikely you need both of them at once.

The [[Extreme Advice Considered Harmful]] chapter of [[TheAPIBook]] talks about symmetry. It describes how harmful seeking for an absolute symmetry at all costs can be. The chapter argues that there often isn't a need for both [[GettersAndSetters]], that in many cases just getters in an [[API]] are enough. Similar example can be given for [[PullXorPush|pull vs. push]] in [[API]]s - it is unlikely you need both of them at once.

== Push like Example ==

== Push like Example ==

</source>

</source>

It is easy to mimic '''push''' approach when you have a chance to to register for a '''pull'''. Just like avoiding both [[SettersAndGetters]], never support both [[PullXorPush|pull & push]] in the same core [[API]].

It is easy to mimic '''push''' approach when you have a chance to to register for a '''pull'''. Just like avoiding both [[GettersAndSetters]], never support both [[PullXorPush|pull & push]] in the same core [[API]].

[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Anti]]

[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Anti]]

== Don't Pull & Push at Once! ==

== Don't Pull & Push at Once! ==

The thing to remember is that (unless there are threading issues), it is always possible to simulate the '''push''' approach with the '''pull''' one. E.g. it makes no sense to design an [[API]] that supports both - prefer the '''pull''' approach as the more flexible one. One can always turn push into pull:

The thing to remember is that (unless there are [[ImpossibleThreading|threading concerns]]), it is always possible to simulate the '''push''' approach with the '''pull''' one. E.g. it makes no sense to design an [[API]] that supports both - prefer the '''pull''' approach as the more flexible one. One can always turn push into pull:

<source lang="java">

<source lang="java">

}

}

</source>

</source>

This has some benefits (and it can even be improved to work without the '''registerTranslation''' method with [[Lookup]] based registration or even more with [[Annotation Processor]]s) over the '''push''' version. One doesn't have to load languages until they are really needed. Also one can translate unknown words - if the word to translate is in plural, it is the language implementation can make additional adjustments and convert it to singular form, translate it and then (in the target language) translate it back to plural. Or one can translate even words that don't make sense - by looking up the closest alternative.

This has some benefits (and it can even be improved to work without the '''registerTranslation''' method with [[Lookup]] based registration or even more with [[AnnotationProcessor]]s) over the '''push''' version. One doesn't have to load languages until they are really needed. Also one can translate unknown words - if the word to translate is in plural, it is the language implementation can make additional adjustments and convert it to singular form, translate it and then (in the target language) translate it back to plural. Or one can translate even words that don't make sense - by looking up the closest alternative.

This is the value of the '''pull'''-approach - one gets a callback and can adjust to it when needed.

This is the value of the '''pull'''-approach - one gets a callback and can adjust to it when needed.

</source>

</source>

in a system of such kind you require all translation [[modules]] (it probably makes sense to assume the translations are developed independently, right?) to eagerly - e.g. as early as possible - register themselves into the system and provide necessary details. From which language they translate words, to which language and what is the vocabulary they can handle. This is probably too premature - better to ask when needed.

in a system of such kind you require all translation [[module]]s (it probably makes sense to assume the translations are developed independently, right?) to eagerly - e.g. as early as possible - register themselves into the system and provide necessary details. From which language they translate words, to which language and what is the vocabulary they can handle. This is probably too premature - better to ask when needed.

== Pull like Approach ==

== Pull like Approach ==

The [[Extreme Advice Considered Harmful]] chapter of [[TheAPIBook]] talks about symmetry and how harmful seek for full symmetry can be - the chapter argues that there often isn't a need for both [[GettersAndSetters]], that in many cases just getters are enough. Similar example can be given for pull vs. push [[API]]s - it is unlikely you need both of them at once.

The [[Extreme Advice Considered Harmful]] chapter of [[TheAPIBook]] talks about symmetry. It describes how harmful seeking for full symmetry at all costs can be. The chapter argues that there often isn't a need for both [[GettersAndSetters]], that in many cases just getters in an [[API]] are enough. Similar example can be given for [[PullXorPush|pull vs. push]] in [[API]]s - it is unlikely you need both of them at once.

== Push like Example ==

== Push like Example ==