Сгусток данных

В объектно-ориентированном программировании «группа данных» — это имя, данное любой группе переменных , которые передаются вместе (группой) в различных частях программы. Комок данных, как и другие запахи кода , может указывать на более глубокие проблемы с проектированием или реализацией программы. Группа переменных, которые обычно составляют группу данных, часто тесно связаны или взаимозависимы и в результате часто используются вместе в группе. Сгусток данных также известен как особый вид запаха кода на уровне класса , который может быть признаком плохо написанного исходного кода.

Рефакторинг групп данных

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

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

В объектно-ориентированном программировании цель объектов — инкапсулировать как соответствующие данные (поля), так и операции ( методы ), которые можно выполнить с этими данными. Неспособность сгруппировать поля в настоящий объект может препятствовать объединению соответствующих действий.

Длинный список параметров/переменных не обязательно указывает на скопление данных; только когда различные значения здесь тесно и логически связаны, их присутствие считается скоплением данных. Хотя такие случаи редки, метод может законно принимать полдюжины или более совершенно несвязанных параметров, которые невозможно аккуратно превратить в один объект. Однако это говорит о том, что метод пытается сделать слишком много, и его лучше разбить на несколько методов, каждый из которых отвечает за меньшую часть общей ответственности. Это открывает еще одну возможность использовать рефакторинг для улучшения качества кода.

Рефакторинг для устранения комков данных не нужно выполнять вручную. Многие современные полнофункциональные IDE имеют функциональные возможности (часто называемые «Извлечение класса»), которые позволяют выполнять этот рефакторинг автоматически или почти автоматически. Это может снизить стоимость и повысить надежность рефакторинга, что позволит разработчикам, которые в противном случае сопротивлялись бы, сделать это целесообразно.

Пример

Естественно, сгустки данных могут существовать в любом объектно-ориентированном языке программирования. Пример ниже был выбран просто из-за его простоты по объему и синтаксису.

В С#

До рефакторинга

public void AddCoords(int x, int y, int z) { /* … */ }

Пост-рефакторинг

public void AddCoords(Coords coords) { /* … */ }

public class Coords
{
    public Coords(int x, int y, int z)
    {
        X = x;
        Y = y;
        Z = z;
    }

    public int X { get; }
    public int Y { get; }
    public int Z { get; }
}

На Яве

public static void main(String args[]) {
    String firstName = args[0];
    String lastName = args[1];
    Integer age = new Integer(args[2]);
    String gender = args[3];
    String occupation = args[4];
    String city = args[5];
    welcomeNew(firstName, lastName, age, gender, occupation, city);
}

public static void welcomeNew(String firstName, String lastName, Integer age, String gender, String occupation, String city) {
    System.out.printf("Welcome %s %s, a %d-year-old %s from %s who works as a%s\n",firstName, lastName, age, gender, city, occupation);
}

В предыдущем примере все переменные могли быть инкапсулированы в один объект «Person», который можно было передавать отдельно. Кроме того, программист может затем распознать, что welcomeNew метод будет лучше связан с Person class, а затем мог бы придумать другие соответствующие действия, связанные с Person. Например, код можно реорганизовать и расширить следующим образом:

public static void main(String args[]) {
    String firstName = args[0];
    String lastName = args[1];
    Integer age = new Integer(args[2]);
    String gender = args[3];
    String occupation = args[4];
    String city = args[5];

    Person joe = new Person(firstName, lastName, age, gender, occupation, city);
    joe.welcomeNew();
    joe.work();
}

private static class Person {
    /* All parameters have been moved to the new Person class where they are properly grouped and encapsulated */
    String firstName;
    String lastName;
    Integer age;
    String gender;
    String occupation;
    String city;
    
    public Person(String firstName, String lastName, Integer age, String gender, String occupation, String city) {
        this.firstName = firstName;
        this.lastName = lastName;
        this.age = age;
        this.gender = gender;
        this.occupation = occupation;
        this.city = city;
    }
    
    /* Existing functionality relating to the data can also be incorporated into the new class, reducing the risk of scope collision */
    public void welcomeNew() {
        System.out.printf("Welcome %s %s, a %d-year-old %s from %s who works as a%s\n", firstName, lastName, age, gender, city, occupation);
    }
    /* Additionally, the new class may be an opportunity for new functionality to be added */
    public void work() {
        System.out.printf("This is %s working hard on %s in %s", firstName, occupation, city);
    }
}

Хотя это и увеличило длину кода, теперь одного Person можно легко передать как один объект, а не как множество (казалось бы, несвязанных) полей. Кроме того, это дает возможность перемещать связанные методы в класс, чтобы они могли легко работать с отдельными его экземплярами. Эти методы больше не требуют передачи утомительного списка параметров, поскольку вместо этого они сохраняются как переменные экземпляра самих экземпляров объекта.