4 ms·

> instead there were factories and visitors and repositories and facades and I couldn't tell you what else this guy was thinking. Factories: generate objects w

> instead there were factories and visitors and repositories and facades and I couldn't tell you what else this guy was thinking. Factories: generate objects whose type can freely change. See polymorphism. Visitors: create any operation you'd like to implement without having to change a type. See open/close principle. Repositories: separate SQL voodoo from your code and establish a dedicated component to handle database transactions. Façade: isolate the world from all the gory detail in a manner that you are free to change both the component and its clients. See separation of concerns. I find it more worrying that the code developed by a senior developer was dumped just because the junior developer who replaced him was entirely clueless and not obly unable to understand existing codebut also unable to even grasp basic design problems that justify the senior developer's decision. Recommended reading: https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...

milesvp 9y ago
I find it more troubling that someone would think they needed any of these patterns to implement php sessions. What you fail to grasp was the code was so completely unnecessarily complicated that it introduced a fuckton of subtle bugs that were difficult to track down. Things would look like they're working, and then reports of terribly broken behavior forcing an emergency rollback followed by days of trying to figure out what bullshit state things were in to repro the problem. Worse, is so much of the code was some misguided attempt to future proof the code in ways that make no sense. When your code will never have more than a couple dozen simple sql queries you will never benefit from a polymorphic sql class intended to allow the swapping out of your sql backend with another vendor. It's easier just to rewrite that small piece of code when the time comes. Just because you can implement fizzbuzz using a dozen design patterns doesn't mean the problem actually requires it.

milesvp 9y ago

I find it more troubling that someone would think they needed any of these patterns to implement php sessions. What you fail to grasp was the code was so completely unnecessarily complicated that it introduced a fuckton of subtle bugs that were difficult to track down. Things would look like they're working, and then reports of terribly broken behavior forcing an emergency rollback followed by days of trying to figure out what bullshit state things were in to repro the problem. Worse, is so much of the code was some misguided attempt to future proof the code in ways that make no sense. When your code will never have more than a couple dozen simple sql queries you will never benefit from a polymorphic sql class intended to allow the swapping out of your sql backend with another vendor. It's easier just to rewrite that small piece of code when the time comes. Just because you can implement fizzbuzz using a dozen design patterns doesn't mean the problem actually requires it.