Как реорганизовать «строчный» код?

Question

В настоящее время я работаю над кодовой базой, где есть несколько классов переменных, таких как пути к базе данных, которые просто представлены как строки. Большинство операций над этими (не) типами определены в классе утилиты.

Я создал новый класс для представления базы данных с операциями, определенными как методы экземпляра, в традиционном стиле ООП. Однако очень сложно пройти через большую базу кода и реорганизовать ее для использования новых типов. Есть ли у кого-нибудь советы относительно того, как это сделать быстро и эффективно?

Answer 1

Пути доступа к базам данных звучат так, как будто они должны быть Струны для меня. Что еще имеет смысл? И они должны быть экстернализированы либо в конфигурационных файлах, либо в базе данных. Это наименьшее из ваших проблем.

Стойкость была так много раз (например, Hibernate, Spring JDBC, iBatis и т. Д.), Что я задаюсь вопросом, как вы могли бы улучшить их. Если вам нужно решить проблему рефакторинга - и вы должны - я бы посоветовал использовать что-нибудь, кроме того, что вы сделали.

Если вы должны что-то написать, Google для «общего DAO». Вы получите такие вещи, как это:

http://www.ibm.com/developerworks/java/library/j-genericdao/index.html

Если ваша работа не по образцу чего-то подобного, выбросить и переосмыслить вещи.

Answer 2

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

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

Answer 3

Обычно я пытаюсь изолировать строки на границе границы приложения/процесса, например, когда они извлекаются из базы данных или принимаются через веб-операцию.

В этой области применения/процесса часто является идеальным местом для преобразования/преобразования/десериализации строк в более подходящую объектную модель, поддерживаемой любым языком, который вы используете.

Аналогично, объектная модель может быть отображена/преобразована/сериализована обратно в форму строки, когда она выходит из области применения/процесса.

Стоит отметить, что эта строгая типизация может быть несколько тонкой. Обычно я вижу, как xml вторгается в слои приложений и домена. Аналогичный пример из пространства .NET будет не в состоянии сопоставить ADO.NET DataTables (с именами строковых столбцов и нетипизированными значениями полей) в классы/объекты в значительной степени, как только они будут получены. Я не сомневаюсь, что в мире Java существует много аналогичных эквивалентов. Строковая печать не ограничивается только значениями даты, так как шутка идет.

Answer 4

Метод, который я использовал в C# (и просто портирован на Java - извинения, если я сделал ошибку, я новичок в Java) заключается в создании классов StringlyTyped, например.базовый класс

public abstract class StringlyTyped { 
    private String value; 

    public StringlyTyped (String value){ 

     if (value == null){ 
      throw new IllegalArgumentException("value must not be null"); 
     } 
     this.value = value; 
    } 

    public String getValue() { return value; } 

    @Override 
    public boolean equals(Object other){ 
     if (other == this) { 
      return true; 
     } 

     if (other == null || !this.getClass().equals(other.getClass())){ 
      return false; 
     } 

     StringlyTyped o = (StringlyTyped)other; 
     return o.getValue().equals(this.getValue()); 
    } 

    @Override 
    public int hashCode(){ return this.getValue().hashCode(); } 

    @Override 
    public String toString() { return this.getValue(); } 
} 

Тогда производный класс

public class ProviderName extends StringlyTyped { 

    public ProviderName(String value) { 
     super(value); 
    } 
} 

А использование

public void Foo(ProviderName provider) { 
} 

Это имеет смысл, если у вас есть методы со многими Струнные parametrers, например, вы можете избежать

public void Foo(String username, String password, String db, String table, String constraint) 

и вместо того, чтобы иметь код, который сильно типизированных, как это:

public void Foo(UserName username, Password password, DatabasePath db, TableName table...) 

и т.д ...