I have a dejavu feeling when reading [What to do about a 11000 lines C++ source file?] post, but I don't think I can start taking action on my own since I do not have the authority to take action. So I think the first step is to convince people in the organization that big lump of code is bad.
I have a similar situation where there is a single class with 11975 lines of code and every time there are new features, there is a high probability that this class will get bigger and bigger.
Having a huge class isn't bad. If the programmer can manage and understand it, then it is a perfect class. If the programmer is completely lost when he/she tries to change or add something to the class, then it is bad.
With programming, it's all about preference. If they prefer to have a single class of 11975 lines of code, and they can manage it, then it's their choice.
But yes, it is generally bad.
You have my sympathies. Any class that is that huge is inevitably breaking the Single Responsibility Principle, making it difficult to maintain.
My best advice is to lead by example:
Your code will shine like a beacon compared to a the legacy code and your team will understand which code is easier to maintain.
If this class consists of many smaller methods AND these methods actually belong to the class i.e. they are cohesive to each other and the class, then this is not necessarily bad.
The mere fact that a class is large does not make it automatically bad.
What is more important is avoiding a so called "god class" that contains many methods that have no conceptual relation to each other or the class itself.
Keeping the size of the individual methods down is also worth focusing on because most developers will need to "load" a whole method into their brains at one time, not the entire class. So the more concise the method the easier it is for developers to maintain.
You should gather metrics about the number of support issues that can be traced back to code in this class. Also, how long to developers spend making changes to this class compared to other smaller classes? Once you have these metrics you are in a better position to explain to management why such a large class is bad.
In the situation of a large class with a small number of large methods I would use refactoring techniques described in Martin Fowlers book, along with unit tests to ensure no new bugs are introduced.
Once you've refactored a huge method down to a number of simpler understandable methods and have successful unit tests, simply demonstrate this to your colleagues.
At this point, if your colleagues disagree or cannot see a general improvement in the understandability and maintainability of the refactored code, you are dealing with a political/personality problem. In that case it's up to you if you want to continue working in such an environment.
11975 (or is it 12000 already :)) lines of class implementation. Is it bad? Cerainly looks so. But...
It depends. Typically classes which implement the Mediator pattern or the Facade pattern tend to be very large. They have very complex routing / communication protocol. "God" like classes also tend to be very huge and monolithic. In short, A class may actually be large but that may not be a problem.
So instead of focussing on the LOC as a parameter, focus on the functionality / design of the class. Is the class violating Single Responsibility Principle? LOC alone cannot be the only deciding factor to conclude if a class is really huge. Look at other metrics e.g. Cyclomatic Complexity.
However if you conclude that this is really bad in your project's context, you must have a strong reason to convince the relevant stakeholders. For example,
a. Does this class have many bugs?
b. Do this class bug fixes always introduce regression defects? (High coupling, Low cohesion?)
c. How long do defects take to be fixed in this class? How does this compare with other modules?
d. Generate a few UML diagrams for this module to illustrate the important issues (e.g. coupling).
e. Read as much on metrics / consult your Quality / Metrics / QA team and generate sufficient data points. An example of OOAD metrics is here but I am sure there are plenty.
EDIT 2 (some minor changes)
f. Get initial support from some key stakeholders in your sphere of control. Next, get, someone who can present these facts well!. I have seen many things fail at this stage!.
Good luck!
Tell them to summarize what the class does\represents in a minute.
Here's my initial reaction:
There are no suggestions here except refactor what you can. Find whatever functionality violates D-R-Y and then scrub it clean.
Convincing anybody to change existing implementation (especially if "it works") is not easy.
I would start with asking opponents to do the trivial task (from my experience with such extreme classes, I believe there are few large enough methods) like adding something to one of huge methods. It should teach them one lesson: finding the right spot will be really painful. Then, you could ask: "imagine you supporting this class, is it going to be an easy task?".
You may try different approach, but it will probably fail: ask them to write unit test for this code. Or simply ask them to think of any...
Basically those people are not having knowledge on oops? If you do OOAD before starting the project is the better Idea to avoid this, from my experience I can say that every programmer don`t have knowledge on oops, so obviously they cant write a better code.
This is where the difference comes with a programmer and analyst-