Is linkage within an object considered an anti-pattern?

Question

Suppose you have a class that is frequently (or even exclusively) used as part of a linked list. Is it an anti-pattern to place the linkage information within the object?

For example:

   public class Item
   {
       private Item prev; 
       private Item next;
       ...
   }

An often-cited recommendation is to simply use a generic container class (such as java.util.LinkedList in Java), but this creates the overhead of having a separate node object (and the linked object cannot readily refer to its siblings).

Thoughts?

Answer 1

It is not necessarily an anti-pattern. Anti-patterns must have negative side-effects to earn the right to the "anti".

For example, a Node in a Tree data structure would need it's linkage cached inside of the Node. Anything else would violate the much more important concept of encapsulation and localization of data and code based on responsibility of the object.

On the other hand, a Customer data structure that embeds its "next" customer would imply that the Customer data structure is handling two unrelated responsibilities, that of maintaining the Customer data, and that of maintaining the Customer's list data structure. In such a scenario, the two responsibilities could intermingle in ways that impact the ease of maintenance; and hence, would be seen as an anti-pattern.

Answer 2

I think so. It seems to me that you're mixing responsibilities (e.g. if your objects reflect employees, I'd expect to only see employee related properties and methods, not methods and properties related to linked lists).

Sometimes a little overhead is the cost of having "cleaner" designs. Whether or not you're willing to pay for that overhead is a different question. In my opinion, the little overhead added by using utilities like the built-in linked lists is worth it... it saves development time, is thoroughly tested and makes for a cleaner design.

Answer 3

It's an anti pattern if it's not always used in a linked list. You'll end up with a swiss army if you add properties/methods to your classes that you might need. Read about YAGNI.

Adding those methods will also break SRP since the item will also be responsible of keeping track of it's siblings.

Answer 4

In general this is a recommended against because of the creep of features you will need in the future. Even if you don't need features like 'search' and 'sort' currently, someday the specs will change and you'll need to sort your items. If you implement it this way, now you need to implement a sort.

The included linked lists are there because they've been tried, trusted, and debugged. Writing your own function for these is just duplicating a lot of work that's not necessary.

In addition, your worry about having the overhead of an extra object node shouldn't really be too much of a worry - how much extra overhead could it be? In days like today even if they were a kilobyte (which would be crazy) it shouldn't add up to a worry.