простое наследование в Java - PullRequest
       5

простое наследование в Java

2 голосов
/ 28 августа 2010

Предположим, вам нужна бизнес-функция, которая задает какой-то профиль.

Однако в зависимости от способа получения данных настройка профиля будет осуществляться по-разному.

Например, параметры могут быть переданы непосредственно объекту, который сможет

setProfile();

или параметры должны быть обнаружены и переданы в профиль

setProfile(String[] data, Blah blooh);

Каков наилучший подход в такой ситуации? Я имею в виду, дизайн мудрый, как бы вы структурировать это?

Я думал об использовании интерфейса с абстрактными методами, который работает, но вносит некоторый шум. Не совсем уверен, как это лучше структурировать.

Ответы [ 3 ]

5 голосов
/ 28 августа 2010

Я всегда нервничаю из-за методов со многими перегрузками. В этом случае я предпочитаю думать об аргументе метода как о сообщении, а не о параметрах, и создавать один метод, такой как этот:

setProfile(ProfileData data)

Класс ProfileData может содержать данные, общие для всех ваших setProfile подходов, и вы можете создавать производные классы для специализированных setProfile операций.

Этот подход особенно полезен, если вы используете методы сериализации, которые могут автоматически сохранять ваш ProfileData объект на основе его структуры.

3 голосов
/ 28 августа 2010

Я бы хотел абстрагировать фактический профиль в его собственную иерархию классов, чтобы инкапсулировать его и добавить 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
    }
}
0 голосов
/ 28 августа 2010

Для методов Get / Set я всегда сохраняю метод set как один вход.Будь это простой объект, потенциально более сложный объект, как предложил Кбирмингтон.Я думаю, что я делаю это более последовательно, чем любое реальное преимущество в дизайне.

Стоит помнить, хотя, если данные профиля имеют 10 атрибутов и они предоставляют только 9 из них, возможно, вам потребуется 9 различных методов.запись, основанная на том, какой из этих 10 атрибутов фактически отсутствует.

По крайней мере с одной структурой имеется один вход, более того, если структура меняет метод, то не только код внутри него.

В этом аспекте вы программируете интерфейс, который является хорошей парадигмой дизайна.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...