Цепочка методов - почему это хорошая практика или нет?

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

MyObject.Start()
    .SpecifySomeParameter(asdasd)
    .SpecifySomeOtherParameter(asdasd)
    .Execute();

Подход с использованием цепочки методов был необязательным, но он упростил написание кода (особенно с IntelliSense). Имейте в виду, что это единичный случай, который не является общей практикой в ​​моем коде.

Дело в том, что в 99% случаев вы, вероятно, можете обойтись так же или даже лучше без связывания методов. Но есть 1%, где это лучший подход.

Только мои 2 цента;

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

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

РЕДАКТИРОВАТЬ: в комментарии упоминается, что цепочка методов и разрыв строки разделены. Это правда. Однако, в зависимости от отладчика, может или не может быть возможно разместить точку останова в середине оператора. Даже если вы можете, использование отдельных строк с промежуточными переменными дает вам гораздо больше гибкости и целый набор значений, которые вы можете изучить в окне Watch, что помогает процессу отладки.

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

foo.setHeight(100).setWidth(50).setColor('#ffffff');
foo.moveTo(100,100).highlight();

Я не использую его, когда в моем примере один или несколько связанных методов возвращают любой объект, кроме foo. Хотя синтаксически вы можете связать что угодно, пока вы используете правильный API для этого объекта в цепочке, изменение объектов IMHO делает вещи менее читаемыми и может действительно сбивать с толку, если API для разных объектов имеют какое-либо сходство. Если в конце вы вызовете какой-нибудь действительно распространенный метод (.toString(), .print() и т. Д.), На какой объект вы в конечном итоге воздействуете? Кто-то, случайно читающий код, может не уловить, что это будет неявно возвращенный объект в цепочке, а не исходная ссылка.

Объединение различных объектов в цепочку также может привести к неожиданным нулевым ошибкам. В моих примерах, предполагая, что foo действителен, все вызовы методов являются «безопасными» (например, действительны для foo). В примере OP:

participant.getSchedule('monday').saveTo('monnday.file')

... нет никакой гарантии (как сторонний разработчик, смотрящий на код), что getSchedule действительно вернет действительный, ненулевой объект расписания. Кроме того, отладка этого стиля кода часто бывает намного сложнее, поскольку многие IDE не будут оценивать вызов метода во время отладки как объект, который вы можете проверить. ИМО, в любое время, когда вам может понадобиться объект для проверки для целей отладки, я предпочитаю иметь его в явной переменной.

У Мартина Фаулера есть хорошее обсуждение:

Сочетание методов

Когда это использовать

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

Цепочка методов особенно эффективна с такими грамматиками, как parent :: = (this | that) *. Использование разных методов обеспечивает удобочитаемый способ увидеть, какой аргумент будет следующим. Точно так же необязательные аргументы можно легко пропустить с помощью цепочки методов. Список обязательных предложений, таких как parent :: = first second, не так хорошо работает с базовой формой, хотя его можно хорошо поддерживать с помощью прогрессивных интерфейсов. В большинстве случаев в этом случае я бы предпочел вложенную функцию.

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

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

Как:

someList.addObject("str1").addObject("str2").addObject("str3")

лучше, чем:

someList.addObject("str1")
someList.addObject("str2")
someList.addObject("str3")

Исключение может быть, когда addObject () возвращает новый объект, и в этом случае несвязанный код может быть немного более громоздким, например:

someList = someList.addObject("str1")
someList = someList.addObject("str2")
someList = someList.addObject("str3")

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

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

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

Это опасно, потому что вы можете зависеть от большего количества объектов, чем ожидалось, например, тогда ваш вызов возвращает экземпляр другого класса:

Приведу пример:

foodStore - это объект, состоящий из множества ваших продуктовых магазинов. foodstore.getLocalStore () возвращает объект, содержащий информацию о ближайшем к параметру хранилище. getPriceforProduct (что угодно) - это метод этого объекта.

Итак, когда вы вызываете foodStore.getLocalStore (параметры) .getPriceforProduct (что угодно)

вы зависите не только от FoodStore, как вы, но и от LocalStore.

Если getPriceforProduct (что-либо) когда-либо изменится, вам нужно изменить не только FoodStore, но и класс, который вызвал связанный метод.

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

При этом я лично люблю связывать их при программировании Ruby.

Это кажется довольно субъективным.

Цепочка методов - это не что-то плохое или хорошее по своей сути.

Читаемость - это самое главное.

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

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

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

Я знаю, что это надуманный пример, но скажу, что у вас есть следующие классы

Public Class Location
   Private _x As Integer = 15
   Private _y As Integer = 421513

   Public Function X() As Integer
      Return _x
   End Function
   Public Function X(ByVal value As Integer) As Location
      _x = value
      Return Me
   End Function

   Public Function Y() As Integer
      Return _y
   End Function
   Public Function Y(ByVal value As Integer) As Location
      _y = value
      Return Me
   End Function

   Public Overrides Function toString() As String
      Return String.Format("{0},{1}", _x, _y)
   End Function
End Class

Public Class HomeLocation
   Inherits Location

   Public Overrides Function toString() As String
      Return String.Format("Home Is at: {0},{1}", X(), Y())
   End Function
End Class

И скажем, у вас нет доступа к базовому классу, или скажем, что значения по умолчанию являются динамическими, в зависимости от времени и т. Д. Да, вы можете создать экземпляр, а затем изменить значения, но это может стать громоздким, особенно если вы просто передаете значения для метода:

  Dim loc As New HomeLocation()
  loc.X(1337)
  PrintLocation(loc)

Но разве это не легче читать:

  PrintLocation(New HomeLocation().X(1337))

Или как насчет ученика?

Public Class Dummy
   Private _locA As New Location()
   Public Sub New()
      _locA.X(1337)
   End Sub
End Class

vs

Public Class Dummy
   Private _locC As Location = New Location().X(1337)
End Class

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

New Dealer.CarPicker().Subaru.WRX.SixSpeed.TurboCharged.BlueExterior.GrayInterior.Leather.HeatedSeats

Против чего-то вроде

New Dealer.CarPicker(Dealer.CarPicker.Makes.Subaru
                   , Dealer.CarPicker.Models.WRX
                   , Dealer.CarPicker.Transmissions.SixSpeed
                   , Dealer.CarPicker.Engine.Options.TurboCharged
                   , Dealer.CarPicker.Exterior.Color.Blue
                   , Dealer.CarPicker.Interior.Color.Gray
                   , Dealer.CarPicker.Interior.Options.Leather
                   , Dealer.CarPicker.Interior.Seats.Heated)

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

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

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

Заключение

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

Я стараюсь соблюдать эти правила.

1. Старайтесь не цепляться между классами
2. Сделайте подпрограммы специально для цепочки
3. Делайте только ОДНО в рутине цепочки
4. Используйте его, когда он улучшает читаемость
5. Используйте его, когда он упрощает код

Цепочка методов может позволить разрабатывать расширенные DSL непосредственно на Java. По сути, вы можете смоделировать как минимум следующие типы правил DSL:

1. SINGLE-WORD
2. PARAMETERISED-WORD parameter
3. WORD1 [ OPTIONAL-WORD]
4. WORD2 { WORD-CHOICE-A | WORD-CHOICE-B }
5. WORD3 [ , WORD3 ... ]

Эти правила могут быть реализованы с использованием этих интерфейсов.

// Initial interface, entry point of the DSL
interface Start {
  End singleWord();
  End parameterisedWord(String parameter);
  Intermediate1 word1();
  Intermediate2 word2();
  Intermediate3 word3();
}

// Terminating interface, might also contain methods like execute();
interface End {}

// Intermediate DSL "step" extending the interface that is returned
// by optionalWord(), to make that method "optional"
interface Intermediate1 extends End {
  End optionalWord();
}

// Intermediate DSL "step" providing several choices (similar to Start)
interface Intermediate2 {
  End wordChoiceA();
  End wordChoiceB();
}

// Intermediate interface returning itself on word3(), in order to allow for
// repetitions. Repetitions can be ended any time because this interface
// extends End
interface Intermediate3 extends End {
  Intermediate3 word3();
}

С помощью этих простых правил вы можете реализовать сложные DSL, такие как SQL, непосредственно в Java, как это делает jOOQ, библиотека. что я создал. См. Довольно сложный пример SQL, взятый из мой блог здесь:

create().select(
    r1.ROUTINE_NAME,
    r1.SPECIFIC_NAME,
    decode()
        .when(exists(create()
            .selectOne()
            .from(PARAMETERS)
            .where(PARAMETERS.SPECIFIC_SCHEMA.equal(r1.SPECIFIC_SCHEMA))
            .and(PARAMETERS.SPECIFIC_NAME.equal(r1.SPECIFIC_NAME))
            .and(upper(PARAMETERS.PARAMETER_MODE).notEqual("IN"))),
                val("void"))
        .otherwise(r1.DATA_TYPE).as("data_type"),
    r1.NUMERIC_PRECISION,
    r1.NUMERIC_SCALE,
    r1.TYPE_UDT_NAME,
    decode().when(
    exists(
        create().selectOne()
            .from(r2)
            .where(r2.ROUTINE_SCHEMA.equal(getSchemaName()))
            .and(r2.ROUTINE_NAME.equal(r1.ROUTINE_NAME))
            .and(r2.SPECIFIC_NAME.notEqual(r1.SPECIFIC_NAME))),
        create().select(count())
            .from(r2)
            .where(r2.ROUTINE_SCHEMA.equal(getSchemaName()))
            .and(r2.ROUTINE_NAME.equal(r1.ROUTINE_NAME))
            .and(r2.SPECIFIC_NAME.lessOrEqual(r1.SPECIFIC_NAME)).asField())
    .as("overload"))
.from(r1)
.where(r1.ROUTINE_SCHEMA.equal(getSchemaName()))
.orderBy(r1.ROUTINE_NAME.asc())
.fetch()

Еще один хороший пример - jRTF, небольшой DSL, предназначенный для создания документов RTF непосредственно в Java. Пример:

rtf()
  .header(
    color( 0xff, 0, 0 ).at( 0 ),
    color( 0, 0xff, 0 ).at( 1 ),
    color( 0, 0, 0xff ).at( 2 ),
    font( "Calibri" ).at( 0 ) )
  .section(
        p( font( 1, "Second paragraph" ) ),
        p( color( 1, "green" ) )
  )
).out( out );

Цепочка методов может быть просто новинкой для большинства случаев, но я думаю, что она имеет место. Один из примеров можно найти в использовании Active Record в CodeIgniter:

$this->db->select('something')->from('table')->where('id', $id);

Это выглядит намного чище (и, на мой взгляд, имеет больше смысла), чем:

$this->db->select('something');
$this->db->from('table');
$this->db->where('id', $id);

Это действительно субъективно; Каждый человек имеет свое собственное мнение.

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

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

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

Также это:

convertTextToVoice.LoadText ("source.txt"). ConvertToVoice ("destination.wav");

как я обычно его использую. Я обычно не использую его для связывания x параметров. Если бы я хотел указать x параметров при вызове метода, я бы использовал синтаксис params:

public void foo (params object [] items)

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

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

До:

collection.orderBy("column").limit(10);

После:

collection = collection.orderBy("column").limit(10);

В реализации «до» функции модифицировали объект и заканчивали на return this. Я изменил реализацию на вернуть новый объект того же типа.

Моя причина для этого изменения:

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

2. Цепочка методов в системных библиотеках также реализует это таким образом (например, linq или string):

   myText = myText.trim().toUpperCase();
   

3. Исходный объект остается нетронутым, позволяя пользователю API решать, что с ним делать. Это позволяет:

   page1 = collection.limit(10);
   page2 = collection.offset(10).limit(10);
   

4. Реализацию копирования также можно использовать для создания объектов:

   painting = canvas.withBackground('white').withPenSize(10);
   

   Если функция setBackground(color) изменяет экземпляр и ничего не возвращает (как предполагалось).

5. Поведение функций более предсказуемо (см. Пункты 1 и 2).

6. Использование короткого имени переменной также может уменьшить беспорядок в коде, без принудительного использования API в модели.

   var p = participant; // create a reference
   p.addSchedule(events[1]);p.addSchedule(events[2]);p.setStatus('attending');p.save()
   

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

Здесь совершенно упускается из виду, что объединение методов позволяет использовать DRY . Это эффективный заменитель «с» (который плохо реализован на некоторых языках).

A.method1().method2().method3(); // one A

A.method1();
A.method2();
A.method3(); // repeating A 3 times

Это важно по той же причине, по которой СУХОЙ всегда имеет значение; если A оказывается ошибкой, и эти операции необходимо выполнить на B, вам нужно обновить только 1 место, а не 3.

Прагматически преимущество здесь невелико. Тем не менее, я возьму немного меньше набора текста, немного более надежный (СУХОЙ).

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

1.)

participant
    .addSchedule(events[1])
    .addSchedule(events[2])
    .setStatus('attending')
    .save();

vs

participant.addSchedule(events[1]);
participant.addSchedule(events[2]);
participant.setStatus('attending');
participant.save()

2.)

participant
    .getSchedule('monday')
        .saveTo('monnday.file');

vs

mondaySchedule = participant.getSchedule('monday');
mondaySchedule.saveTo('monday.file');

3.)

participant
    .attend(event)
    .setNotifications('silent')
    .getSocialStream('twitter')
        .postStatus('Joining '+event.name)
        .follow(event.getSocialId('twitter'));

vs

participant.attend(event);
participant.setNotifications('silent')
twitter = participant.getSocialStream('twitter')
twitter.postStatus('Joining '+event.name)
twitter.follow(event.getSocialId('twitter'));

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

Я думаю, что единственное место, где такой вид цепочки может быть полезен, - это конвейерные потоки в CLI или объединение нескольких запросов вместе в SQL. Оба имеют цену за несколько утверждений. Но если вы хотите решить сложные проблемы, вы столкнетесь даже с теми, кто заплатит цену и напишет код в виде нескольких операторов с использованием переменных или написанием сценариев bash и хранимых процедур или представлений.

Что касается интерпретации СУХОЙ: «Избегайте повторения знания (не повторения текста)». и «Меньше печатайте, даже не повторяйте тексты». Первое, что на самом деле означает этот принцип, но второе - распространенное недоразумение, потому что многие люди не могут понять слишком сложную чушь вроде «Каждая часть знания должна иметь единственное недвусмысленное выражение, авторитетное представительство в системе ». Второй - компактность любой ценой, что ломается в этом сценарии, потому что ухудшает читаемость. Первая интерпретация прерывается DDD, когда вы копируете код между ограниченными контекстами, потому что в этом сценарии более важна слабая связь.

Мнения Ответ

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

Некоторые вопросы:

• Возвращают ли методы в цепочке новый объект или тот же объект видоизменился?
• Все ли методы в цепочке возвращают один и тот же тип?
• Если нет, то как обозначено изменение типа в цепочке?
• Можно ли безопасно отбросить значение, возвращаемое последним методом?

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

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

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

Добро:

1. Это кратко, но позволяет элегантно уместить больше в одну строку.
2. Иногда можно избежать использования переменной, что иногда может быть полезно.
3. Он может работать лучше.

Плохо:

1. Вы реализуете возврат, по существу добавляя функциональность к методам объектов, которые на самом деле не являются частью того, для чего предназначены эти методы. Он возвращает то, что у вас уже есть, исключительно для экономии нескольких байтов.
2. Он скрывает переключение контекста, когда одна цепочка ведет к другой. Вы можете получить это с помощью геттеров, за исключением того, что это довольно ясно при переключении контекста.
3. Объединение нескольких строк в цепочку выглядит некрасиво, плохо сочетается с отступами и может вызвать некоторую путаницу при обработке оператора (особенно в языках с ASI).
4. Если вы хотите начать возвращать что-то еще, что полезно для связанного метода, вам, возможно, будет сложнее исправить это или столкнуться с большим количеством проблем с ним.
5. Вы передаете управление сущности, которую вы обычно не передаете исключительно для удобства, даже в строго типизированных языках ошибки, вызванные этим, не всегда могут быть обнаружены.
6. Он может работать хуже.

Общий:

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

В некоторых случаях цепочка может серьезно ухудшить читаемость, особенно при взвешивании в точках 1 и 2.

К сожалению, это может быть неправильно использовано, например, вместо другого подхода (например, передача массива) или смешивания методов причудливыми способами (parent.setSomething (). GetChild (). SetSomething (). GetParent (). SetSomething ()).

В типизированных языках (в которых отсутствует auto или эквивалент) это избавляет разработчика от необходимости объявлять типы промежуточных результатов.

import Participant
import Schedule

Participant participant = new Participant()
... snip...
Schedule s = participant.getSchedule(blah)
s.saveTo(filename)

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

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