I came across a question earlier where someone asked how to create an array list with multiple object types (Create an ArrayList with multiple object types?).

The easiest solution is to create a list of objects, but many people mentioned in the replies and comments that using a list of objects is not a good idea, and might even be a code smell. The preferred solution by consensus seems to be a new class that takes in the different types as its parameters.

I can see why creating a list of objects would be problematic, as it's too easy to forget what order the objects are in, what type they are, etc.

I have seen this problem before in code that I've worked with, so I know it's a common blunder.

I was wondering if there is a name for it. Most code smells I've come across have a name, but I don't recall coming across one that described this one. I tried to look it up, but couldn't find anything.

  • 3
    Having an array of Objects doesn't strike me as a code smell. Downcasting them does, and if you're doing anything with them that can't be done with a plain Object that's what you're going to have to do. Aug 27 '20 at 2:58
  • 1
    Code smells, in general, don't have names. Anti-patterns do, but those are pretty vaporous as well. Aug 27 '20 at 3:48
  • 1
    @RobertHarvey sourcemaking.com/refactoring/smells and en.wikipedia.org/wiki/Code_smell both list multiple code smells by name. Conspicuously missing is the one I described in the above post, however...
    – Calculemus
    Aug 27 '20 at 4:49
  • 1
    Does it need a name? "A code smell by any other name smells just as bad." Aug 27 '20 at 7:43
  • 2
    I'm not sure this is a problem and qualifies as a code smell. Think of JSON, XML, YAML, ... The whole point of these representations is that they are very generic and can handle multiple types in a list or dictionary. Aug 27 '20 at 7:54

I think the situation you described is a special case of a more general phenomenon I have seen several times: abusing some loosely typed container for creating and managing data records which actually deserve an abstraction on their own. This does not always come along in form of a list of objects, but also in form of dictionaries, string lists, tuples and sometimes just pairs or triples of variables which are passed around together from one method to another.

To clean up such mess, one has to introduce a type or class, give it an appropriate name, then introduce some member variables, give them appropriate names, too, and then think about further steps like moving parts of the code into methods of that newly created class. I guess finding a good name is often what stops people from doing this at first place, naming things well is one of hardest problems in Computer science.

Is there a specific, broadly accepted name for this kind of "code smell"? I honestly don't know, I would probably call it a "missing abstraction". However, the different refactorings for cleaning up such code have names in Fowler's refactoring catalog. The most suitable ones for fighting the described phenomenon (like "Extract class" or "Encapsulate Record", or "Combine Functions into Class") are listed in the encapsulation section of that catalog. In the long run, I guess the names of these ways to improve code will probably be more useful than any names for "bad" code.

  • 1
    In the spirit of some of our previous discussions, I held off on casting a close vote to see how this question would play out. Alas, the result has been predictably disappointing, and I've decided to cast the final close vote. The problem, of course, is that visitors should be asking about their particular issue, concern or topic, and not using the site as a proxy for Google search. Aug 27 '20 at 16:15
  • 1
    @RobertHarvey I actually spent about an hour before creating this question combing through Google search results and found nothing relevant. So I did not use the site as a proxy for Google search, because Google isn't currently smart enough to offer a good answer to my question. The answers here turned out to be helpful for me, regardless of how disappointing they may have been to you.
    – Calculemus
    Aug 27 '20 at 18:00
  • @RobertHarvey: I agree that "name that thing" question are mostly not very interesting or enlightning, and this one is probably no exception. That does not mean, however, that this specific question cannot be answered in a sensible way. Of course, I took the freedom to interpret the question not too literally, but in the sense of "is the described observation part of a bigger picture". Should the question be closed? Well, five people voted for closing it, I am fine with that. Should it be deleted? ...
    – Doc Brown
    Aug 28 '20 at 9:42
  • ... I don't think so, the question and its answers seem to have a value for some readers, not just for the OP. Not every question & answer asked on this site is "worth for nomination of the question of the month", that's true, but IMHO that does not mean we should only accept questions which fall into such a category.
    – Doc Brown
    Aug 28 '20 at 9:46

It might not be a code smell but it might lead to code smells.

If we think of an array as construct that groups items together, books[] or movies[] being simple examples, then is there anything common about the objects and why they are stored in the same array or group? As mentioned by other it might indicate a common interface. IReadable or IWatchable.


The name is lack of type safety. You toss in a bunch of objects and leave it up to the consumer of the objects to figure out what they really are and cast them back to their subtypes. Which can go wrong at runtime. You would rather have some verification at compile time.

It is not necessarily bad to have different types in the same collection but you would expect some interface or common base type (with polymorphism) to go with it so they can be treated as one type.

Not the answer you're looking for? Browse other questions tagged or ask your own question.