I see no sensible reason for this "pattern". As you say, the desired functionality would better be implemented by a static function, although stepping back a bit further the global nature of the suits is also a code smell: what happens if you want to model both bridge and (say) tarot, with its different suits in the same program? A better design would involve a SuitCollection or similar.

What can you do about it? That depends a lot on context. If this is a commercial project, talk to your peers to see if there's a good reason for this decision, and if not go and talk to whoever have you that response in person and try and discuss things. If it's an open source project or similar, my personal advice would be "run away" - poor quality code combined with poor communications isn't going to make for a fun project.

I see no sensible reason for this "pattern". As you say, the desired functionality would better be implemented by a static function; while it's possibly/probably true that using a constructor to do this doesn't actually produce any functional issues, it breaks the Principle of Least Surprise: like you, I look at that code and think "Huh!? What's going on here then?". I see no advantage to doing it this way over having a static function.

Stepping back a bit further the global nature of the suits is also a code smell: what happens if you want to model both bridge and (say) tarot, with its different suits in the same program? A better design would involve a SuitCollection or similar.

What can you do about it? That depends a lot on context. If this is a commercial project, talk to your peers to see if there's a good reason for this decision, and if not go and talk to whoever have you that response in person and try and discuss things. If it's an open source project or similar, my personal advice would be "run away" - poor quality code combined with poor communications isn't going to make for a fun project.