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?

Improve this question
13
  • 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? Commented Aug 12, 2015 at 22:44
  • 1
    It's not a smell or antipattern. Commented Aug 12, 2015 at 23:05
  • 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. Commented Aug 12, 2015 at 23:13
  • 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. Commented Aug 13, 2015 at 0: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. Commented Aug 13, 2015 at 0:39

0

Reset to default

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.