New developers (less than 10 years professional experience) seem to become fascinated by "cool" language features that let them do unintuitive things and then approach problem solving with a mindset of "What cool tricks can I do to solve this?"
Instead, the experienced developer will always approach a problem with "What is the simplest way to solve this problem?"
This is how they become expert programmers in 10 years. Of course they will produce a couple of brainfarts and quite a few over engineered or just too clever solutions on the way, but this is how you learn.
The alternative is to just write the same conservative solution for ten years. Then you are just as medioker programmer after ten years as when you started.
Sometimes the simplest way is to use a "cool" language feature.
For instance: say you have an app with 30 different ViewControllers, and you need them to respond to the same notification. Sure, you could go back and refactor every one to subclass from another class that inherits from UIViewController - but then you need to make that for UITableViewControllers and UICollectionViewControllers, and potentially any other new view controllers that come along if your codebase ends up lasting for years.
Or, you could make one class category that method swizzles the viewDidAppear method to add the notification handling in immediately. Every class that inherits from UIViewController will now respond to that notification.
I think a lot could be said here for maintainability. As others have mentioned, it really goes a long way to take the time and refactor the class to inherit the extra/common functionality if you are working on a team or working on a project that you know will live a very long time. Swizzling will certainly work, but at what cost to readability, debugging and reuse? That's normally the question I ask before swizzling or doing fancy, dynamic things.
Sometimes the quickest or even the most elegant solution isn't necessarily the "best" one. Best being a subjective term, I would say it depends on what you need from your code over time and with whom.
New developers (less than 10 years professional experience) seem to become fascinated by "cool" language features
The classic analogy is with young musicians. Just because you can put a fancy ornament in or play real fast doesn't necessarily mean you should. Sometimes it's best to play something simple, so long as it's just the right something simple.
Yeah, but what sucks is when you object for the reasons you describe, but your objections are interpreted as you being out-of-touch, afraid of new things, etc. When really it's just a distaste for complexity and magic.
Well. Objective-C isn't that simple to begin with, but when you are used to it, it really provides elegant and very simple solutions to medium complex stuff like key-value observing and coding. Meditated together they are called bindings, where your ui is key value coded, and your model is key value observed. Yes, Objective-C (and Cocoa) are very strong on design patterns, which gives you a whole lot of leverage. It works and is debugable too! :) I love it, and find it to be the most hot-dirty-sexy language I have ever used.
First you have to master the tool, or even abuse it, then you get experienced. Or, you refuse to try those advanced language features and never get experienced.
> Instead, the experienced developer will always approach a problem with "What is the simplest way to solve this problem?"
And what would you call my mindset, which can be summarized as "what cool features I can use to express the problem and it's solution in a simplest way"?
Remember, copy pasting is also very simple solution to many common problems.
New developers (less than 10 years professional experience) seem to become fascinated by "cool" language features that let them do unintuitive things and then approach problem solving with a mindset of "What cool tricks can I do to solve this?"
Instead, the experienced developer will always approach a problem with "What is the simplest way to solve this problem?"