First: congratulations for the book, I love it, it's my new bible after "Working effectively with legacy code" and "refactoring".
Here is my question. I really enjoyed/still enjoy reading this book, but I'm an easy target, I believe in elegance in code, I like it, I feel good and proud when my code is easy to read.understand.
I work in a team where some guys (please sit down and take a Xanax) like "copy and paste" because "every class is independent" and hate my code because "There are too much classes and interfaces it's too complicated" and like "to put everything in one class because we exactly know where everything is".
How can I convince/turn them (like vampires) without loosing my calm and alienate them to me?
This is always an interesting conversation. I have had similar discussions in several jobs.
My personal style is to refactor everything within an inch of its life, and ruthlessly remove duplication. I have found, however, that this approach can occasionally increase rather than decrease future maintenance work. The key point for me is not to simply assume that the benefits of separating and factoring everything are always obvious. Or even always valid.
For example. One part of our product has a core section, common to all customers, but each customer also has a "skin", comprising both customer-specific behaviour and look-and-feel templates. A common way to set up for a new customer is to copy the "skin" from an existing customer, then modify it as we learn and agree what the new customer needs. Experience has shown that customer "skins" are usually different enough that attempting to eliminate every duplication and share common aspects between them only ends up costing more development effort to split them apart again when they inevitably differ.
So, here's a strategy to sort this out in your case:
First, find out about the usual development tasks performed by the "copy-n-paste" people. Is their work part of a single growing "core" codebase, or is each piece a separate chunk, perhaps for a separate customer?
Then find out about the people, skills, management and hiring process. Are such developers expected to work together on a core product, or do they work alone on their own bits? Are developers moved about, hired and fired at will, and expected to pick up each small task without understanding the rest of the system? Is the system understandable and self-documenting or is it a ball of confusion?
All of these factors can influence whether refactoring to remove duplication, or duplicating to increase independent clarity is a "survival skill".
Eventually you should find yourself in a position where you can help the organisation realise that duplication suits a small range of circumstances, but refactoring to eliminate duplication (in my experience, at least) suits a much wider range. With that understanding in place, choosing whether to duplicate or refactor can begin to be done based on parts of the system, rather than individual preference.