MultiplePersonalityDisorder is a DesignSmell you often find in classes that are "trying to do too much:"
The methods of the class implement multiple useful abstractions instead of focusing on just one.

This is often a symptom of FearOfAddingClasses.

A classic example of classes with MultiplePersonalityDisorder are typical "RecordSet" implementations:  A RecordSet is the result you get from issuing a SELECT statement that may return multiple rows.  The problem is that a typical RecordSet implements the union of all the functionality of the following three abstractions:
	1. Hold a Collection of result rows.
	2. Be an Iterator over those rows -- offering a "view" into one row at a time.
	3. Be the row itself -- enabling access to the data values for each of the columns.

While simple usage may be easier with a MultiplePersonalityDisorder class, non-trivial usage quickly becomes confusing and conflicted:  What should you do if you want to open another cursor/Iterator on a ResultSet collection?  Why you 'clone()' it of course.  But notice that clone only copies one of the three personalities:  You can't clone a row instance, to modify it and insert it into the database as a new row -- the rows are no longer first class objects when their functionality is folded into a RecordSet.  You can't clone the "Collection" of records for comparison later either -- it's not a first class object either.

Resolution:
Break RecordSet functionality into three separate classes.
Simplify the design by adding classes.

----

Be aware that the 'static' methods of a class can grow in complexity to the point of needing to be a separate class.
This is another variant of the MultiplePersonalityDisorder problem, in class designs.

----

My latest inspiration:
TestCase in JUnit (JavaUnit) is two things:
An instance of this class is one (interface) Test to run, so in that sense we're talking about "Test Cases."
But the child classes implemented by developers are collections of test methods to be executed.
Really, this makes them Test Suites.

"So what's the problem?!?  It works doesn't it???"

Well yes, but it's confusing.
If the test case instance functionality were provided by a separate class,
then TestCase could be given a more meaningful name (related to the kind of TestSuite it really is) and have more focused functionality.

----

One clear sign of an MPD is a member variable call ''m_mode''. Especially if it remains unchanged for the life of an object, drives a lot of 'if' or 'switch' statements, etc.

----
CategoryAntiPattern