wiiki - RampantClassification

The insane compulsion to make every single tiny little insignificant thing into a class, no matter its triviality or lack of behaviour.

Apparently it's written down in TheManual somewhere that everything should be an object. This is somehow misread as EVERYTHING MUST be an object.

Sufferers cannot be reasoned with.

Maybe it works for them. A room full of Taxomaniacs might just be productive, you never know. Just because it does not work for you does not mean it is objectively less effective for everybody else. (BenefitsAreSubjective)

-- AnthonyLander

This confuses me. If TheManual concerned is a SmalltalkLanguage manual, then everything will be an object. What else could it be? If, conversely, the manual were a SchemeLanguage one, then everything would be a procedure. And so on (there's a loose sense of "everything" here). If this is indeed an AntiPattern, then it needs a clear context. -- KeithBraithwaite

(Actually everything is an object. But that does not mean that everything must be an object. A little ontology check. Ref: MostlyHarmless. -- AlistairCockburn)

TILT! Alistair, are you talking about programs or the world?

Side discussion moved to EverythingIsAnObjectVerb.

Sorry, Keith. You're right. My initial description was unclear. Let me give you an example from real-life(tm):

A class called PartNumber with exactly one instance variable, number and only get and set methods. People sometimes make classes like this because PartNumber is, technically, a domain object (and hence is deserving of a class).

This is fundamentally evil because the only thing you can do with an instance of PartNumber is violate encapsulation.

RampantClassification is turning everything into a class whether or not it's warranted.

-- AnthonyLander

The mists clear. You've put your finger on it Anthony.

A few years ago a similar discussion to this occurred on a modelling course I attended. The question was, would the matriculation number identifying a student in a university registration system belong to a class. Answer: no. The reason given at first was that a matric number has no structure. But, for UK undergrads, they do:

matriculation-number ::= year ucas-number check-digit
year                 ::= <digit> <digit>
ucas-number          ::= <digit>{6}, -- serial number of your original application
check-digit          ::= <digit>

the real reason is that we don't care what structure a matric number has.

This is the sort of situation where, here in Java land, I really wish I could typedef Integer. -- KB

I'd like to argue that everything as domainish as Part Number does in fact need to be an object. The cost is low, and the cost of retrofitting the code from using plain numbers is quite high. It's inconvenient to search the code for all uses of integers to find the ones that are intended to be part numbers, when it turns out that

part numbers have to occur in the catalog to be legal
part numbers from Ford have letters in them
part numbers have to know how to put themselves out in XML

As a card-carrying XPer, I'm not heavily into antici (say it) pation, but if it's a concept, encapsulate it. -- RonJeffries

No fair, Ron. You're cheating. Your PartNumber class has behaviour. Having said that, though, I agree completely. The rule (and I suppose the point of this page) is simply: Think before you type. --AnthonyLander

Perfectly fair. Ron's comment was when it turns out. ie. we using a ValueObject instead of an integer because it makes future ReFactor**ings much easier. The behaviour examples Ron gave would be discovered further down the road.

Especially in software, everything has exactly as much and as little behavior as you feel like giving it. Making it a class announces either (but usually both): I don't want to know (about it's insides) / I'm betting I'm going to glom some behavior onto this puppy before long. As Ron says, if it's in the domain, odds are that it'll get some behavior. And if it doesn't, the relational database people will be happy, AND I won't have to look at its insides ever again. -- AlistairCockburn

Well, I'm certainly not going to defend RampantClassification, especially since I think it's an AntiPattern...but you're reminding me of another one called WhatIfInheritance. -- AnthonyLander

Well, your mileage is going to vary. In my matric number example, once you'd been given a number by the admissions system, you really didn't care how it had been built. And the most complex thing that happened to them was being printed out. In that case, in C/C++ I'd typedef from int (by reflex, really); in Java, I'd extend Integer (since matric numbers are immutable values), but not add any methods. -- Keith

But Integer is final.

If a part number is just a number, and an employee number is just a number, then should the two kinds of numbers be able to be used interchangeably? Is there no value in the static type-checking that occurs from creating separate classes for them?

If a class has a method

move(double distance);

how does it know if the distance is in feet, inches, meters, or whatever? Perhaps you might wish to have the overloaded methods

move(Feet distance);
move(Inches distance);
move(Meters distance);

But, you should be able to add distances measured in Feet to those measured in Inches. This argues for a Length class. But in Java, you can't overload operators, so that is extremely inconvenient.

So DontDoThat then! (writing in Java)

But yes, numbers usually have DimensionalityPlusUnit.

You can't add a length to a voltage (hmm, I'm trying to think of an exception here), but you could divide a voltage by a length (to get a field strength).
You can add a mile, a metre and five millimetres. It would be convenient if your numbers did the unit conversions for you, because you don't want to have to remember to do it yourself. That's what compilers are for. (Maths works nicely like this.)
You can do strange things like adding "miles east" to "miles north" (to get a vector) or adding 5 + 3i (a complex number). You can generalize this in amusing ways. Two apples plus one orange is three pieces of fruit.
I claim without proof 8-) that some DimensionallyConsistent additions are insane anyway: Bohr radius plus one cubit, or Avogadro's number and a half.
Some numbers are quantized, for example integers (!) and energy levels of electron orbitals.
Something odd happens to dimensionless numbers that can cause them to be incompatible, but I don't know a name for this. A ratio of lengths plus a cardinal looks odd.

Of course, a language that copes with this will require more configuration and CPU, but configuration only happens once-ish per app and I expect some of the checks and units can be done statically. I imagine that some domain-specific languages would cover PhysicalNumbers like this. [I can't think of a more suitable WikiName at the moment.] -- MatthewAstley

Of course, if you insist on using C++ typedef's instead of creating classes, then none of this applies. Typedefs are bad juju. They just create aliases rather than truly defining new types.

TaxoMania is a problem, but isn't it slightly different from Anthony's original concern that often (in environments were not everything need be an instance of a class), everything is forced to be an instance of a class?

Well if part number has any format at all, there only certain numbers that would be valid, so it should be a class. An int is ok for simple numbers... but not for domain types, and a part number is most certainly a domain type. If part number weren't a type, then you could create a part with any random int, obviously bad.

CategoryAntiPattern