Преимущества цепочки
то есть, где я люблю его использовать
Одним из преимуществ цепочки, о котором я не упомянул, была возможность использовать его во время инициализации переменной или при передаче нового объекта в метод, не уверенный, является ли это плохой практикой или нет.
Я знаю, что это надуманный пример, но скажем, у вас есть следующие классы
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
против
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
Vs Что-то вроде
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, это может сбить с толку, когда вы вызываете подпрограммы для передачи другим классам к одному из методов цепочки.
Существует также опасение, что подпрограмма выдаст недопустимые данные, поэтому до сих пор я использовал цепочку, только когда возвращаю тот же вызываемый экземпляр. Как указывалось, если вы создаете цепочку между классами, вы усложняете отладку (которая вернула ноль?) И можете увеличить взаимосвязь зависимостей между классами.
Заключение
Как и все в жизни и программировании, создание цепочек не является ни хорошим, ни плохим, если вы можете избежать плохого, тогда создание цепочек может быть большим преимуществом.
Я стараюсь следовать этим правилам.
- Старайтесь не цепляться между классами
- Сделайте подпрограммы специально для
цепочки
- Делать только одну вещь в цепочке
рутина
- Используйте, когда это улучшает читаемость
- Используйте его, когда он упрощает код