This question already has an answer here:
This topic relates to web development / software engineering; however the question can be related to other fields of expertise involving a more junior employee being more technically skilled than a senior with more experience.
I work in a team where the absolute extent of object oriented programming used is inheritence. Procedural code is placed in class methods. There is little to no typehinting in method signatures, no namespaces or interfaces - (I know, right)? - This has lead to legacy code that is hard to maintain and very difficult for new staff (juniors) to pick up and work on. Only the person who wrote it knows really how it works.
In a technical meeting on a new project, I anticipate any discussion on good OO practices (design patterns, etc.) will most likely be met with "it's too complex". Too complex being 5 classes or more.
I am polite, calm, respectful and honest, and so is the senior developer - he's a friend. As a result, he honestly believes that anything above inheritance in programming is "too complex" and I honestly believe it isn't - having written code in the past that 'just worked' as it was fully unit tested by myself and worked flawlessly on release-day, and the senior's code required a few fixes.
How can I put forward a good object oriented solution that is architecturally sound and 'makes sense' in this meeting but avoid the "it's too complicated" issue (when it really isn't, it's just he is used to coding in procedural style). I have the greatest respect for my senior, but I want to avoid the terrible, procedural code (in classes) that our legacy application now has.
How can a more junior person, with much less experience, but significantly more drive (having learned these concepts and put them into practice on multiple occasions), convince a senior that this way is the best way, with adequate respect and tact?