3 ms·

I think this is where a lot of Rubyists/Pythonistas get lost. Just because the languages hide ideas like "interface" and "abstract base class" doesn't mean that

by bitops 15y ago

I think this is where a lot of Rubyists/Pythonistas get lost. Just because the languages hide ideas like "interface" and "abstract base class" doesn't mean that those concepts aren't useful. Particularly in Ruby-land there's been a push to have common interfaces. They're only enforced by contract. And if you think about it, having "interface" explicitly in the language just means that the contract is enforced at compile time. Even so, you have to be careful. You could implement an interface and still just return null.

Goladus 15y ago
> I think this is where a lot of Rubyists/Pythonistas get lost. Just because the languages hide ideas like "interface" and "abstract base class" doesn't mean that those concepts aren't useful. I agree, somewhat. The problem is that HtDC seems to spends so much time on vocabulary and describing how to construct classes that very little is left over for discussion of actual design. Here's an excerpt: This first section on classes suggests that the design of a class proceeds in three steps: 1. Read the problem statement. Look for statements that mention or list the attributes of the objects in your problem space. This tells you how many fields you need for the class definition and what information they represent. That is probably quite reasonable from a java-perspective. But in Python the best answer might be to use the built-in data structures, define a bunch of functions to operate on that data, which are automatically encapsulated in a namespace based on the name of the file. But it might not, sometimes you would want to define a class with explicit fields. The question is, how do you know which technique to use? This book doesn't seem to help with that. We've jumped from a data-driven approach using scheme to a java-style object-oriented approach for no apparent reason and very little explanation of the benefits of this approach. Even if the part about interfaces might help a bit with designing a Python module, in order to get that out of this book you're going to have to wade through a lot of other stuff.

by bitops 15y ago

Goladus 15y ago

> I think this is where a lot of Rubyists/Pythonistas get lost. Just because the languages hide ideas like "interface" and "abstract base class" doesn't mean that those concepts aren't useful. I agree, somewhat. The problem is that HtDC seems to spends so much time on vocabulary and describing how to construct classes that very little is left over for discussion of actual design. Here's an excerpt: This first section on classes suggests that the design of a class proceeds in three steps: 1. Read the problem statement. Look for statements that mention or list the attributes of the objects in your problem space. This tells you how many fields you need for the class definition and what information they represent. That is probably quite reasonable from a java-perspective. But in Python the best answer might be to use the built-in data structures, define a bunch of functions to operate on that data, which are automatically encapsulated in a namespace based on the name of the file. But it might not, sometimes you would want to define a class with explicit fields. The question is, how do you know which technique to use? This book doesn't seem to help with that. We've jumped from a data-driven approach using scheme to a java-style object-oriented approach for no apparent reason and very little explanation of the benefits of this approach. Even if the part about interfaces might help a bit with designing a Python module, in order to get that out of this book you're going to have to wade through a lot of other stuff.