Что такое высокая когезия и как ее использовать / сделать?

объяснение того, что это такое от Стива Макконнелла Код:

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

какой-то способ добиться этого от дяди Боба Код:

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

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

понятие сплоченности тесно связано с понятием кроме того, существует принцип, основанный на эвристике высокой когезии, называемый принципом единой ответственности (S от SOLID).

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

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

например, класс электронной почты. Она обязательно должна содержать элементы данных, из, копия, скрытая копия, тема, тело, и может содержать эти saveAsDraft методов(), отправить(), discardDraft(). Но login () здесь быть не должно, так как есть ряд протоколов электронной почты, и должны быть реализованы отдельно.

Когезия обычно измеряется с помощью одной из метрик LCOM (отсутствие когезии), исходная метрика LCOM пришла из Chidamber и Kemerer. См., например:: http://www.computing.dcu.ie / ~renaat/ca421/LCOM.html

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

псевдокод Связного класс:

class FooBar {
  private SomeObject _bla = new SomeObject();

  public void FirstMethod() {
    _bla.FirstCall();
  }

  public void SecondMethod() {
    _bla.SecondCall();
  }

  public void ThirdMethod() {
    _bla.ThirdCall();
  }
}

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

псевдокод плохо Связного класса:

class FooBar {
  private SomeObject _bla = new SomeObject();
  private SomeObject _foo = new SomeObject();
  private SomeObject _bar = new SomeObject();

  public void FirstMethod() {
    _bla.Call();
  }

  public void SecondMethod() {
    _foo.Call();
  }

  public void ThirdMethod() {
    _bar.Call();
  }
}

класс делает одно дело принцип Принцип Единой Ответственности, который исходит от Роберта С. Мартина и является одним из SOLID принципы. Принцип предписывает, что класс должна быть только одна причина для изменения.

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

Это пример низкой сплоченности:

class Calculator
{


     public static void main(String args[])
     {

          //calculating sum here
          result = a + b;
          //calculating difference here
          result = a - b;
          //same for multiplication and division
     }
}

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

class Calculator
{


     public static void main(String args[])
     {

          Calculator myObj = new Calculator();
          System.out.println(myObj.SumOfTwoNumbers(5,7));
      }


     public int SumOfTwoNumbers(int a, int b)
     {

          return (a+b);
     }

     //similarly for other operations

}

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

также a принцип сухой-не повторяйся

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

в MSDN это статья об этом, вероятно, более информативна, чем Википедия в этом случае.

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

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

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

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

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

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

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

например, функция, которая вызывает исключение или задает глобальную переменную ошибки (errno в C) или должны использоваться в последовательности (strtok() функция является примером из стандартной библиотеки C, поскольку она поддерживает внутреннее состояние) или которая предоставляет указатель, который затем должен управляться или выдает журнал какой-либо утилите журнала, являются примерами функции, которая больше не является функциональной связью.

Я прочитал как оригинальную книгу Yourdon, так и Константина, Structured Programming, где я впервые столкнулся с идеей сплоченности в 1980-х годах и практическим руководством Meilir Page-Jones по проектированию структурированных систем, и Page-Jones сделал гораздо лучшую работу описание как сцепления, так и сцепления. Книга Юдона и Константина кажется немного более академичной. Книга Стива Макконнелла Code Complete довольно хороша и практична, и в пересмотренном издании есть что сказать о хорошей практике программирования.