Я бы хотел абстрагировать фактический профиль в его собственную иерархию классов, чтобы инкапсулировать его и добавить Generics к setProfile()
.Конечно, он добавляет некоторую сложность, но поскольку он также вводит косвенность, код будет более разобщенным, что в конечном итоге должно оказаться полезным.
Кроме того, фактическая функция может быть полностью в собственной иерархии классов, чтобычастично подключаемый, что означает, что у вас в руках будет шаблон стратегии .Решение применить это, однако, потребовало бы большего знания системы, которую вы строите, и может не подходить для того, что вы создаете.
Быстрый пример:
/**
* Interface for describing the actual function. May (and most likely does)
* contain other methods too.
*/
public interface BusinessFunction<P extends Profile> {
public void setProfile(P p);
}
/**
* Base profile interface, contains all common profile related methods.
*/
public interface Profile {}
/**
* This interface is mostly a matter of taste, I added this just to show the
* extendability.
*/
public interface SimpleProfile extends Profile {}
/**
* This would be what you're interested of.
*/
public interface ComplexProfile extends Profile {
String[] getData();
Blah blooh();
}
/**
* Actual function.
*/
public class ComplexBusinessFunction implements BusinessFunction<ComplexProfile> {
public void setProfile(ComplexProfile p) {
// do whatever with p which has getData() and blooh()
}
}
/**
* And another example just to be thorough.
*/
public class SimpleBusinessFunction implements BusinessFunction<SimpleProfile> {
public void setProfile(SimpleProfile p) {
// do whatever with the empty profile
}
}