I&#x27;d like to mention that despite OOP being in the title, I thought this book had a lot to teach that isn&#x27;t specific to OOP architecture or OOP languages. Really, I think the star of the show is TDD and refactoring.For a short intro to Sandi&#x27;s style and approach, I always recommend this 35min talk: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;OMPfEXIlTVE?si=Ird6t8uDN86T06Y7" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;OMPfEXIlTVE?si=Ird6t8uDN86T06Y7</a>Aside from any specifically educational content, as a talk it is fantastic - funny, smart, well put together.

I was so lucky to have run into poodr when I did. Early enough in my career to still feel like I didn&#x27;t know anything, but with just enough experience to have encountered the problems she was addressing &quot;in the wild.&quot; Absolutely formative for me I have no idea where I&#x27;d be without it. The only other book to even approach its impact for me is working effectively with legacy code.

Sandi&#x27;s earlier book, POODR, was also great. While it is focused on Ruby, most of the advice applies more broadly.Reading these two really helped me understand just how impoverished the concept of OOP has become by C++ and Java, from its Smalltalk roots.

Concur. I took Sandi&#x27;s workshop based on the 99 Bottles book, in Ruby with a Ruby crowd, but was immediately able to apply it to Python programming.Very helpful and clear thinking about refactoring out complexity—and not just refactoring for its own sake, but under the constraint that you want to move your program forward, add new functionality, etc. Refactoring with a direction, purpose, and direct payoff.

This is one of my favorite software development books of all time. It&#x27;s the book that finally offered straight forward guidance and wisdom on how to properly utilize OOP language features.I&#x27;m very happy to see it out for Python!

The problem: How do you have examples that are simple enough for those learning the refactoring tricks and techniques to quickly grok and be able to work on, and not overly complicated by the kinds of &quot;real-world complexities&quot; that do regularly appear in &quot;real-world code.&quot;I had the same &quot;this isn&#x27;t realistic!&quot; complaint when studying the book, but the examples nonetheless helped me see, practice, and adopt the techniques so that I could immediately apply them to the complex production examples I needed to improve. YMMV... but as a former skeptic, &quot;trust the process.&quot; Walk that path an work those examples for 5 days, then see how you feel. I was already pretty skilled, including in complex refactorings, and it still leveled me up.

Maybe this is misguided, but it feels a bit to me (comparing the ruby and js versions for example) that this is using the same code examples in both, and neither are really typical of the sorts of code people in either language community would actually write?

&gt; The 2nd Edition contains 3 new chapters and is about 50% longer than the 1st.I&#x27;ve never really had the problem that I&#x27;ve read an OOP text and felt &quot;this was too short&quot;.

I checked it but found only the same pages as you. This is the reason I asked.

You could check?The site says, &quot;Available in digital form only (epub, kepub, mobi, pdf). Includes separate books for JavaScript, PHP, Python, and Ruby languages, and beer and milk beverages.&quot;There is no mention of needing special software to read them, so I think it&#x27;s safe to guess that there is no DRM. And it&#x27;s sold directly by the author. Publishers are generally the ones who insist on DRM. It would not surprise me if there was watermarking, but that is not DRM.

Is the book DRM free? Sorry to be this paranoid, but you cannot be sure today.

While I understand the complaints against OOP, I highly recommend this book to anyone working in an environment where they&#x27;re working with OOP languages&#x2F;frameworks. There are plenty of Ruby&#x2F;Rails shops out there still. At the very least I love the mentality that this book teaches and often recommend Tidy First by Kent Beck at the same time.

I have the book and don&#x27;t speak Ruby at all. Nevertheless, is so we&#x27;ll written, that you can take the lessons and apply them in any language with virtual polymorphism. A Python version of the book means bigger audience, to the benefit of the trade.

Previous DiscussionBottles of OOP - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12129821">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12129821</a> - July 2016 (71 comments)

Mainstream OOP languages (looking at you Java) have failed to make composition as convenient as inheritance.

Why on earth do you put composition and OOP as opposing techniques? Composition is just one more technique in the OOP toolbox and there is nothing in OOP that mandates an inheritance based architecture.

But I&#x27;ve read the book, and her solution to the &quot;bottles of beer&quot; problem involves encoding all the logic into an elaborate class hierarchy!I&#x27;m not rabidly anti-OOP, but the point at which I turn against it is when the pursuit of &quot;properly&quot; modelling your domain with objects obscures the underlying logic. I feel like this book reaches that point. This is her stance on polymorphism:&gt; As an OO practitioner, when you see a conditional, the hairs on your neck should stand up. Its very presence ought to offend your sensibilities. You should feel entitled to send messages to objects, and look for a way to write code that allows you to do so. The above pattern means that objects are missing, and suggests that subsequent refactorings are needed to reveal them.Absolutely not! You should not, as a rule, be replacing conditional statements with polymorphic dispatch. Polymorphism can be a useful tool for separating behaviour into modules, but that trade-off is only worthwhile when the original behaviour is too bloated to be legible as a unit. I don&#x27;t see an awareness of that trade-off here. That&#x27;s my problem.

What’s funny is I did composition for a take home project when interviewing at a place and they said the approach was too complicated and failed me for it. They wanted multiple inheritance instead. Fair enough. Their codebase probably had a lot of it and my not showing it probably told them I didn’t understand it.

I used to work at a flask shop that did views with 3-5 or more inherited classes. Nobody could really follow how everything worked. It was insane.Anyways yeah give me composition and flat classes all day long.

Then you&#x27;re going to be pleasantly surprised, because composition is actually a genuine OOP technique and Sandi Metz advocates for exactly this kind of sane OOP focused on encapsulation and objects making sense, instead of masturbating with class hierarchies.

&gt;I’m gonna buy the book but I prefer composition over OOP.The GoF book (the design patterns book) says in a page right near the start, &quot;Prefer composition over inheritance&quot;, in the middle of an otherwise blank page, presumably to emphasize the importance of that advice.As others have replied, composition is one technique you can use in OOP, not something that is the opposite of OOP.You can also use composition in non-OOP procedural languages like C, by having a struct within a struct.<a href="https:&#x2F;&#x2F;www.google.com&#x2F;search?q=can+you+have+nested+structs+in+c" rel="nofollow">https:&#x2F;&#x2F;www.google.com&#x2F;search?q=can+you+have+nested+structs+...</a>

These are complementary not contradictory ideas. One of the principal takeaways from the Ruby edition (and many of Sandi Metz’s conference talks) is undoubtedly a mindset of, and techniques for, writing compositional OO code.

I’m gonna buy the book but I prefer composition over OOP. I prefer to have an init that takes some params where those params are fully baked clients of whatever services I need and then the class just uses them as needed. I don’t see a lot of value in having a Python class that might have a few or more classes that it extends where all the functions from all the classes crowd up the classes namespace.Class Foo.__init__(self, db, blob_storage, secrets_manager, …)Instead of class Foo(DB, BlobStorer, SecretsMgr)Etc

I have seen quite a few digital books at this price point now. Personally I feel it is quite high, but I assume I am in the minority?

It definitely took me quite a bit of time from I joined HN until I learned that if you edit your submission title then you can override the automatic edits that HN makes to the title you originally submitted.And I would guess that likewise there are still a lot of people that don’t know this.Also, sometimes one might not realize that the title got changed until it’s too late to edit the title of the post.

Note to anyone who submits an article: If the title gets mangled like this, edit it.

There&#x27;s already a bottle web framework [1]. It came out around the same time as Flask I think. It might have even started as a spoof of Flask even? Or vice versa?[1] <a href="https:&#x2F;&#x2F;bottlepy.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;bottlepy.org&#x2F;</a>

Here I was assuming bottles might fit nicely into the Flask ecosystem.

It’s supposed to kill clickbait titles. In practice it just randomly mangles titles. I don’t get why they don’t remove the feature and instead rely on flagging.

Why does HN automatically edit titles??

&gt; HN&#x27;s automatic title editing strikes again.Demonstrating for the umpteenth time that automated clairvoyance is an idiotic idea.

HN&#x27;s automatic title editing strikes again. The title of this submission should presumably be: &quot;99 Bottles of OOP now available in Python&quot;.

a) I&#x27;m not sure what OOP is, and it doesn&#x27;t seem like the people who tout it are either. I&#x27;m sure someone would look at code I think is good and call it OOP, and someone who wouldn&#x27;t. It is so many buzzwords old at this point that using it is more a label of a viewpoint than a coding style. Combined with the book&#x27;s apparent focus on TDD and carefully selecting names, it zeros me precisely in on a set of people I have worked with over the years. I don&#x27;t, as a rule, like the code those people generate.b) The best style is no style, or at least pick a more recently popular dogma like FP, at least it gets you easy&#x2F;safe parallelism in exchange for throwing some of the tools out of your toolbox.

A. OOP as practically implemented for the last 25 years is glueing functions to stateB. Functions and structs.

OOP is a mental crutch that breaks complex problems down into a easy mentally discoverable world&#x2F;domain model with objects that have a life of their own, that is capable to derive correct results to complex problems via the relations of the objects.Meanwhile its creators can not hold the whole complexity in mind (often barely in spec) and still can produce a artifact that produces correct results.

&gt; OOP is an industry of its own which generates a ton of incidental complexity.I think you&#x27;re confusing &quot;OOP is used in projects and I&#x27;ve seen accidental complexity in projects&quot; with &quot;OOP generates accidental complexity&quot;.The truth of the matter is that developers create complexity. It just so happens that the vast majority use OOP.I challenge you to a) start by stating what you think OOP is, b) present any approach that does not use OOP and does not end up with the same problems, if not worse.

Is your argument that1. its ok to add incidental and unnecessary complexity2. so long as it&#x27;s less complex than your most complex component?Because that&#x27;s a formula we can all agree leads no where good nor productive.

&gt; OOP is an industry of its own which generates a ton of incidental complexity.And that &quot;ton&quot; is still miniscule compared to front-end development which almost completely eschews OOP and has 10x more incidental complexity.I guess my point is that, while OOP&#x27;s incidental complexity is large, it&#x27;s still insignificant compared to other technology stacks which developers are showing a great appetite for anyway. Things like &quot;incidental complexity&quot; is irrelevant to developers anyway, today, at the tail end of 2024.IOW, OOP introduces significantly less $BAD_THING, when the clear majority of developers don&#x27;t even care about the quantity of $BAD_THING in the first place, making the whole &quot;should we use OOP&quot; argument moot.Doesn&#x27;t matter if you use it or not, the extra introduced incidental complexity is still going to be insignificant due to the complexity load of the entire project, more so in front-end.Hence, there&#x27;s no point in having the argument in the first place.

&gt; OOP is an industry of its own which generates a ton of incidental complexity.Code in any form can generate a ton of incidental complexity. The issue isn&#x27;t the tool rather than the education to properly wield those tools. Especially when you introduce the team dynamic where everyone has varying understandings of what is being built and how it should be built.

As it pertains to Python in particular I think OOP is great for libraries but of limited usefulness at the application layer. Things like pytorch&#x27;s nn.module IMO is a great abstraction, but every time I&#x27;ve tried to map some concrete business concept to an OOP construct I&#x27;ve regretted it.

OOP is an industry of its own which generates a ton of incidental complexity. See &quot;Object-Oriented Programming is Bad&quot; by Brian Wills (<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=QM1iUe6IofM" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=QM1iUe6IofM</a>) and most of Rich Hickey&#x27;s excellent videos, especially his keynote at Rails Conf 2012 where he basically told the Ruby crowd they&#x27;re doing it wrong (<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=rI8tNMsozo0" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=rI8tNMsozo0</a>).

Look at the fastest linting&#x2F;build tools&#x2F;runtimes for JavaScript. They are mostly not written in JavaScript, because JavaScript is slow and no amount of hotspot profiling&#x2F;optimization will fix that. This is also why Python&#x27;s core data types for dictionaries and so on are not implemented in Python.You can also look at any microbenchmark between pure Python and a native language of your choice, even one that uses GC like OCaml or Go, and unless the Python code has been written so that it spends all its time calling C code the way you sometimes can with regex-heavy code, Python will generally lose by a varying margin. These micro inefficiencies multiply at every level hundreds of times over to create needlessly slow, inefficient applications.The truth is I can link benchmarks, case studies of app rewrites from Ruby to Go or something comparable, measurements about the results of using NIFs in Erlang&#x2F;Elixir, etc. all day long but you&#x27;ll ignore all of them.

Can you actually give an example?I believe in mechanical empathy. I think developers should - win performance is a concern - think about how their code ends up on the CPU, what ends up on the heap, how caches are used, and so on.But for most Python developers, and Ruby developers, it&#x27;s more important, in more use cases, to have clear and readable code that is easily maintainable.I&#x27;ve met Sandi, I&#x27;ve gone through her Ruby books, I recommend her teaching and her books to others. I don&#x27;t see the problem.If you need ASM, use ASM. If you&#x27;re on a team doing OOP, maybe learn about OOP.

I&#x27;m glad my comment noting the usage of best practices when it comes to writing Python was downvoted. Says a lot about the immature user base around here.

Thank you for using snake_case.That&#x27;s all I got. Best of luck!