Каков наилучший способ высушить эти классы, дублирование во всем, кроме конструктора - PullRequest
2 голосов
/ 09 июля 2010

Итак, я провел некоторый рефакторинг, и два моих класса теперь выглядят точно так же, за исключением их конструкторов.

Классы обертывают объект API, который не очень красив, и добавляют некоторые функциональные возможности, которые принадлежатedge of the API.

class A extends API {
  public A {
    this.APIOption = Option1;
    this.AnotherAPIOption = Option2;
    // a few more
  }

  public ArrayList<String> somethingTheAPIDoesntDo() {
    // Do something the API doesn't provide but I use alot
  }
  // Other shared methods
}

class B extends API {
  public B {
    this.APIOption = Option3;
    this.AnotherAPIOption = Option4;
    // a few more
  }

  public ArrayList<String> somethingTheAPIDoesntDo() {
    // Do something the API doesn't provide but I use alot
  }
  // Other shared methods
}

Имеет ли смысл помещать общий код между ними в класс Abstract Base, и чтобы подклассы реализовывали свои конструкторы только с настройками специализированных опций?Это имеет смысл на бумаге, но что-то кажется странным / нелогичным.Я пропускаю здесь образец?

Возможное решение для сушки

class A extends BetterAPIBase {
  public A {
    this.APIOption = Option1;
    this.AnotherAPIOption = Option2;
    // a few more
  }
}

class B extends BetterAPIBase {
  public B {
    this.APIOption = Option3;
    this.AnotherAPIOption = Option4;
    // a few more
  }
}    

abstract class BetterAPIBase extends API {
  public Better APIBase() {}
  public ArrayList<String> somethingTheAPIDoesntDo() {
    // Do something the API doesn't provide but I use alot
  }
  // Other methods
}

РЕДАКТИРОВАТЬ

Статическая фабричная модель хороша, но я думаю, что я также могудобавьте интерфейс, который включает в себя общие методы, которые я добавил.

Я бы сделал так, чтобы класс BetterAPI также реализовывал IBetterAPI, который предоставил бы только те методы, которые я добавил, везде, где я объявляю тип экземпляра как IBetterAPI.

interface IBetterAPI{
      public ArrayList<String> somethingTheAPIDoesntDo();
      // other methods I added in BetterAPI
}

//somewhere else:
IBetterAPI niceApi = BetterAPI.createWithOptionSetA();
niceApi.somethingTheAPIDoesntDo();

// Can't do this, nice and hidden.
niceApi.somethingBaseAPIDoes(string uglyOptions, bool adNauseum); 

Ответы [ 2 ]

13 голосов
/ 09 июля 2010

Не проще ли иметь один класс с параметризованным (возможно частным) конструктором и несколькими статическими фабричными методами?

class BetterAPI extends API {
  private BetterAPI(APIOption option, AnotherAPIOption anotherOption) {
    this.APIOption = option;
    this.AnotherAPIOption = anotherOption;
  }

  public static BetterAPI createWithOptionSetA() {
    return new BetterAPI(Option1, Option2);
  }

  public static BetterAPI createWithOptionSetB() {
    return new BetterAPI(Option3, Option4);
  }

  // ...
}

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

1 голос
/ 09 июля 2010

Это довольно близко к тому, что я бы сделал.Хотя, если «немного больше» приводит к большому количеству избыточного кода в конструкторе, я бы написал:

abstract class BetterAPIBase extends API { 
  public BetterAPIBase(String APIOption, int AnotherAPIOption, ... more ...) {
    this.APIOption=APIOption;
    this.AnotherAPIOption=AnotherAPIOption;
    // a few more
  } 
  public ArrayList<String> somethingTheAPIDoesntDo() { 
    // Do something the API doesn't provide but I use alot 
  } 
  // Other methods 
} 

class A extends BetterAPIBase { 
  public A { 
    super(Option1, Option2, ... more ...);
  } 
} 

class B extends BetterAPIBase { 
  public B { 
    super(Option3, Option4, ... more ...);
  } 
}     

Конечно, если какое-либо из значений параметра совпадает, им не нужно было быбыть принятым, вот где наступит настоящее устранение избыточности.

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