3 ms·

> What is asserted without evidence can be dismissed without evidence I was hoping the code in the article would form (an admittedly small) piece of evidence.

> What is asserted without evidence can be dismissed without evidence I was hoping the code in the article would form (an admittedly small) piece of evidence. I'd just really like someone to show off a nice neat counter example, that demonstrates the true beauty of Python OO, and is "unrefactorable" to a data types + functions equivalent. Pathlib is a great example, maybe a canonical one, of: > Very occasionally, you come up with a core type that's used so often, it's nice to have the cutesy stuff. Django's class based views I think could probably reasonably refactored into data types + functions. I'm not too au-fait with Django or its internals, but if someone could send me a "demonstration Django clone in 800 lines", I'd give it a go. > What if client_a and client_b write to different APIs? ... Then you use an if statement to split at that point. Again, given a specific toy example, I'm fairly certain a reasonable refactor is possible.

nicbou 6y ago
> Then you use an if statement to split at that point This quickly falls apart as the difference between the classes grow. A view that turns a Facebook API call into Post-like Facebook objects has very little in common with a view that turns Twitter API call into Post-like Twitter objects. Doubly so if you factor other parts of the request like authentication, pagination and rate-limiting. You'll need a bunch of if-else statements in a bunch of different places. This gets even hairier when you need to test that code. It's a lot easier to make sure a FacebookView calls the right endpoint and returns the right data, than to test every path of a combination of if-else blocks. And what if you want to extend this code, but don't have control of it (external module or different team)? It's easy to extend parts of a class that do exactly one thing. It's not easy to extend big if-else block without overwriting it. I have seen the benefits of this approach first-hand. We got more reliable code and better test coverage with less effort, and greatly simplified maintenance and development. > I'm fairly certain a reasonable refactor is possible To what benefit? There is already a nice construct for self-contained objects that offer a similar interface, that can be inherited from, and that can be unit-tested. Objects.

nicbou 6y ago

> Then you use an if statement to split at that point This quickly falls apart as the difference between the classes grow. A view that turns a Facebook API call into Post-like Facebook objects has very little in common with a view that turns Twitter API call into Post-like Twitter objects. Doubly so if you factor other parts of the request like authentication, pagination and rate-limiting. You'll need a bunch of if-else statements in a bunch of different places. This gets even hairier when you need to test that code. It's a lot easier to make sure a FacebookView calls the right endpoint and returns the right data, than to test every path of a combination of if-else blocks. And what if you want to extend this code, but don't have control of it (external module or different team)? It's easy to extend parts of a class that do exactly one thing. It's not easy to extend big if-else block without overwriting it. I have seen the benefits of this approach first-hand. We got more reliable code and better test coverage with less effort, and greatly simplified maintenance and development. > I'm fairly certain a reasonable refactor is possible To what benefit? There is already a nice construct for self-contained objects that offer a similar interface, that can be inherited from, and that can be unit-tested. Objects.