Should child objects not know parents while in views/view code?

Question

As of iOS 6, Apple thought Unwind Segues would be added to their layout/views. What this means is, when you're on the 7th view of a stack, you can pop back to any other one. For those of you pure OO fans (like myself), I cringed a little. I cringed even more when I learned these also work with pop-ups.

Why would a modal on top of a stack know about the Nth view before?

I'm a big fan of OO because when you stick to its principles, you don't get spaghetti. And once you have a complex set of modals that are shared among multiple navigation controllers, these Segues begin to cluster into a bunch of lines on your storyboard that effectively don't enhance the navigation (as compared to an Obj-Oriented solution), but take up space on your Storyboard.

If you change a parent view, you immediately break the unwind segue and have to edit all the code that pointed to it, which is one of the exact same reasons we avoid doing this in code.

This has made me cringe for awhile, and I don't see any questions that bring this up in relation to views.

Answer 1

Immutability is a principle in more than OOP.

Isolation is a principle in more than OOP.

Reaching out and touching whatever you feel like is a bad idea for the same reason pouring glue over the gears of a clock is a bad idea. Sure it holds the clock together but that only works well now. Eventually you want things to be able to move.

Functional programmers will complain about this by talking about side effects. They’ll insist on avoiding them until the last minute.

OOP programmers will complain about this by talking about the service locator pattern and tell you to instead use pure dependency injection to make your dependencies explicit.

Lazy programmers will keep doing it anyway because they know by the time anyone catches them at it they’ll already be at a different Job.

Rather than rail against the inevitable learn to refactor. Rather than preach ideals show how they can be followed. Rather than ask people to have faith show them the real benefits.

Either that or update the ol’ resume.

Answer 2

The primary goal is not that your software follows some principles, but that the software provides the user experience that it should provide.

If your user interface designer declares - after thoughtful analysis - that the user should go from a three times nested inner screen directly to the outmost screen, then that’s what your code needs to do. If you do this with code that goes against your principles, tough.

Apple has created this method because some people, in some situations, want to go straight to a specific screen sometimes. Much better than doing it by hand because you only get one animation, and your code stays unchanged if intermediate levels change.

Answer 3

Child objects should be able to get access to their parents.

Sure, from a philosophical point of view, they shouldn't, every piece of data should be nicely partitioned, etc. Unfortunately the real world has a tendency to bulldoze over every 'elegant' model without a second thought. So, if you make something with airtight, but abstract OO principles, you will likely make something useful for only a very small subset of problems, and make impossible everything else.

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.”

That's not to say you should abandon all reason, and make a tangled ball of mud and spaghetti. But, sometimes real-world problems need bits of zip-ties and duct tape in certain places, because no model will ever match the complexity of the real world.

if you make the language impossible to do stupid things in, you'll also make it impossible to do clever things