0

I am in a current iteration between design and implementation, and ended up with the following "one-liner":

IEnumerable<Channel> ActiveChannels = Receiver.AcquisitionInfo
                                              .ActiveIndices
                                              .Select(v => Receiver.Sensors
                                                                   .SelectMany(s => s.Channels)
                                                                   .ElementAt(v));

Basically, in the class where this code appears, I need to know, from the available channels, which of those are activated. There is an AcquisitionInfo object holding the list of Sensors with their respective Channels, and so on.

Just by looking to the code, it is obvious that it has some "syndrome". Just like the saying "he wanted a banana, but got a gorilla holding a banana and the whole forest!", or, like some blogger has stated: "imagine if you go to the grocery clerk, take off your pants and hand it to him, so that he can take your wallet from the pant's pocket, and then take the proper amount of money from the wallet."

So, is there a name for this smell / anti-pattern? If not, how could I characterize it and, most important, how should I refactor it?

heltonbiker
  • 1,048
  • possible duplicate of Is code like this a "train wreck" (in violation of Law of Demeter)?, How to solve “train wreck” properties problem that violates Law Of Demeter? – outis Aug 12 '15 at 22:44
  • Note that chaining isn't the issue–it could be the use of a fluent interface. It's the "talking to strangers" that's the LoD violation (though it's more what you'd call a "guideline" than an actual rule). – outis Aug 12 '15 at 22:51
  • @outis Interesting! Since I posted the question in quest for a "well known name" for this smell / anti-pattern, would you say that "train wreck" is known enough that searching for it would guide me to what I need to know to solve it? Because if the answer is "yes", then you could put it as an answer (unless you can't do so because of the duplication issue). – heltonbiker Aug 12 '15 at 22:57
  • 1
    It's not a smell or antipattern. – Robert Harvey Aug 12 '15 at 23:05
  • @RobertHarvey Well, some call it so... "The train wreck anti pattern occurs..." http://c2.com/cgi/wiki?TrainWreck – heltonbiker Aug 12 '15 at 23:11
  • 1
    You missed the real name of the antipattern in that comment, which is "Law of Demeter," not "train-wreck." There is no "train-wreck" antipattern. In any case, it's not a violation of the Law of Demeter, and the "train wreck" example provided above is not the same thing that you're describing here. – Robert Harvey Aug 12 '15 at 23:13
  • @RobertHarvey Excuse me, but I'm confused... The Law of Demeter is not an anti-pattern, it's a principle, isn't it? And I fail to see how a Train Wreck is not a violation of that law... – heltonbiker Aug 12 '15 at 23:17
  • Are we really having this conversation? Look up the definition for "train wreck." It's a general metaphor, not a named antipattern. It has very little to do with code smells specifically, and I don't particularly care if I got my logic backwards. The information you're looking for is in the topic "Law of Demeter;" *look there.* – Robert Harvey Aug 12 '15 at 23:32
  • 2
    I personally wouldn't consider this a violation of the LoD anyway. This isn't imperative code that looks through an object hierarchy picking out a chain of properties, it's a bit of declarative code that describes what data to select. Declarative code just looks awkward when you are thinking imperatively. – Eric King Aug 13 '15 at 00:32
  • 1
    @EricKing it also isn't a LoD violation because it isn't doing introspection on the innards of something you were given. It's a framework for transforming one collection into another. The LoD is often misconstrued to be "no more than one dot" which is, well... wrong. This isn't a train wreck because you won't suddenly get a NPE in one object that you then try to deference. This is functional/declarative-esque programming that uses . instead of the lisp-ish style of (). It is important to try to understand LINQ before one starts complaining how many . are used when writing a statement. –  Aug 13 '15 at 00:39
  • @MichaelT Agreed – Eric King Aug 13 '15 at 00:40
  • @MichaelT thank you for your elaboration, it's a lot clearer to me now! – heltonbiker Aug 13 '15 at 01:48
  • It's a bit of a smell in my opinion, and many experienced developers dislike it. There's a thread on CodeProject.com right now about it, and generally their take on this style is negative. In my experience, younger developers like to do this. "Fluent" APIs like this are fairly new and trendy. Personally, I like the Linq syntax that resembles SQL queries; things like left joins seem much more natural than they do in the "fluent" syntax. – user1172763 Jul 21 '16 at 14:36

0 Answers0