Рекомендации по разработке классов

From AsIsWiki
Jump to: navigation, search
Форум

Назад | Оглавление | Дальше


Contents

Всегда храните данные в переменных, объявленных как private

Главное требование: не нарушайте никапсуляцию.

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

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

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


Всегда инициализируйте данные

Java не инициализирует локальные переменные, но поля объектов инициализируются автоматически.

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


Не используйте в классе слишком много простых типов

Несколько связанных между собой полей простых типов следует объединять в новый класс. Такие классы проще для понимания, и их легче модифицировать. Например, следующие четыре поля в классе Customer надо объединить в новый класс Address:

private String street;

private String city;

private String state;

private int zip;

Представленный таким образом адрес легче изменять.


Не для всех полей надо создавать методы доступа и модификации

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

Однако есть поля, которые после создания объекта не изменяются.

К ним относится массив аббревиатур названий штатов США в классе Address.


Используйте стандартную форму определения класса

Содержимое класса всегда перечисляется в следующем порядке:

  • общедоступные элементы;
  • элементы, область видимости которых ограничена пакетом;
  • закрытые элементы.

Внутри каждого раздела перечисляются:

  • методы экземпляра;
  • статические методы;
  • поля экземпляра;
  • статические поля.

Пользователей класса больше интересует открытый интерфейс, чем детали закрытой реализации. Кроме того, их больше интересуют методы, чем данные.

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


Разбивайте на части слишком большие классы

Совет слишком общий: что кажется "слишком большим" одному, вполне нормально для другого. Но если есть очевидная возможность разделить один сложный класс на два класса, воспользуйтесь ею. Опасайтесь обратной крайности. Вряд ли оправданы десять классов, в каждом из которых есть только один метод.

Пример плохого стиля:

class CardDeck {  // плохой стиль

    public CardDeck() {
        ...
    }

    public void shuffle() {
        ...
    }

    public int getTopValue() {
        ...
    }

    public int getTopSuit() {
        ...
    }

    public void draw() {
        ...
    }
      
    private int[] value;
    private int[] suit;
}

В этом классе реализованы две разные концепции:

  • Карточный стол с методами shuffle() (тасование) и draw() (раздача).
  • Игральная карта с методами для проверки ранга и масти карты.

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

class CardDeck {

    public CardDeck() {
        ...
    }

    public void shuffle() {
        ...
    }

    public int getTopValue() {
        ...
    }

    public int getTopSuit() {
        ...
    }

    public void draw() {
        ...
    }
      
    private Card[] cards;
}
    
class Card {

    public Card(int aValue, int aSuit) {
        ...
    }

    public int getValue() {
        ...
    }

    public int getSuit() {
        ...
    }
      
    private int[] value;
    private int[] suit;
}


Давайте классам и методам осмысленные имена

Классы и переменные лучше именовать осмысленно. В стандартной библиотеке есть примеры нарушения данного правила: класс Date описывает время, а не дату.

Удобно принять следующие соглашения:

  • Имя класса должно быть:
    • существительным (Order);
    • прилагательное + существительное (RushOrder);
    • герундий + существительное (BillingAddress).
  • Методы доступа должны начинаться словом get (getSalary).
  • Модифицирующие методы должны начинаться словом set (setSalary).



Форум

Назад | Оглавление | Дальше

Personal tools
Namespaces

Variants
Actions
Navigation
Tools