la recherche d'un cas d'utilisation spécifique où une sous-classe et une classe dans le même package doivent accéder à un champ ou une méthode protégée ...
Eh bien pour moi, un tel cas d'utilisation est plutôt général que spécifique, et il découle de mes préférences pour:
- Commencez avec un modificateur d'accès aussi strict que possible, en ne recourant à un ou plusieurs plus faibles que plus tard, si cela est jugé nécessaire.
- Faites en sorte que les tests unitaires résident dans le même package que le code testé.
D'en haut, je peux commencer à concevoir pour mes objets avec des modificateurs d'accès par défaut (je commencerais par privatemais cela compliquerait les tests unitaires):
public class Example {
public static void main(String [] args) {
new UnitTest().testDoSomething(new Unit1(), new Unit2());
}
static class Unit1 {
void doSomething() {} // default access
}
static class Unit2 {
void doSomething() {} // default access
}
static class UnitTest {
void testDoSomething(Unit1 unit1, Unit2 unit2) {
unit1.doSomething();
unit2.doSomething();
}
}
}
Note latérale dans l'extrait ci-dessus Unit1, Unit2et UnitTestsont imbriqués dans Exampleun souci de simplicité de présentation, mais dans un projet réel, j'aurais probablement ces classes dans des fichiers séparés (et UnitTestmême dans un répertoire séparé ).
Ensuite, lorsqu'une nécessité survient, j'affaiblirais le contrôle d'accès par défaut à protected:
public class ExampleEvolved {
public static void main(String [] args) {
new UnitTest().testDoSomething(new Unit1(), new Unit2());
}
static class Unit1 {
protected void doSomething() {} // made protected
}
static class Unit2 {
protected void doSomething() {} // made protected
}
static class UnitTest {
// ---> no changes needed although UnitTest doesn't subclass
// ...and, hey, if I'd have to subclass... which one of Unit1, Unit2?
void testDoSomething(Unit1 unit1, Unit2 unit2) {
unit1.doSomething();
unit2.doSomething();
}
}
}
Vous voyez, je peux garder le code de test unitaire ExampleEvolvedinchangé car les méthodes protégées sont accessibles à partir du même package, même si l'accès à l'objet n'est pas une sous-classe .
Moins de changements nécessaires => modification plus sûre; après tout, je n'ai changé que les modificateurs d'accès et je n'ai pas modifié les méthodes Unit1.doSomething()et les Unit2.doSomething()actions, il est donc naturel de s'attendre à ce que le code de test unitaire continue de s'exécuter sans modifications.
protectedsous-classe est uniquement? Honnêtement, pendant longtemps, j'avais l'impression que