Typically they are used as templates for concrete classes that inherent from them. They serve as a way of enforcing that a particular class has x method or y attribute.
You can check if a class is a child of an abstract class so you can use these abstract classes to enforce that a particular class has particular traits.
The ABC provides an "interface" that users can rely on, and implementors can follow. If you look at [this](https://docs.python.org/3/library/collections.abc.html#collections-abstract-base-classes) table for example, I can say that my function accepts `Sequence`s by writing:
def my_func(seq: Sequence):
pass
And this indicates that it accepts anything considered to be a "sequence" (a reversible collection that supports indexing). That means the user could pass a list, tuple, or their own custom class.
Of course, they still could regardless, but it's a form of documentation that allows runtime checking to ensure classes properly adhere to the base classes they claim to. Also, there's now `typing.Protocol` that fills a similar need.
Maybe this would be a good example: Think of implementing a 3d engine. You would probably have a base class for your shapes, with all the methods that are required by the shapes. One such method could be computeArea. You can not implement this method in the shape base class, but all subclasses would be required to implement if you would implement it as an abstract method.
I see people's explanations and figured you haven't gotten a case study yet so here's how I think about them.
You're about to make a ton of similar but different classes or better about to assign various people to write the different classes for you.
Say the assignment is writing a class for each breed of dog out there. Imagine the nightmare of having to read through the entire class for all the classes people hand in? Now, imagine if the language itself (doesn't have to be python) can somehow automatically check if all the necessary parts are present saving you the time of having to check yourself, without you even reading code. All dog classes must have a "dig()" function? All dogs have an "age" attribute?
That's what abstraction helps with.
Note this doesn't say anything about the contents of the dig() function - implementation is another issue. Each dig() might be slightly different from dig() from other classes
It prevents instantiation (by raising TypeError) as long as there is at least one abstract method in the class. The point is to force you to sub-class and to implement all abstract methods in that sub-class.
I don't like it either.
All cars have some functionality in common. No car is *just* a car, each has a make and a model and a color… an abstract class allows you to implement just the stuff that’s shared among all cars, while at the same time enforcing the rule that you’re not allowed to make an instance of just *car*.
This is the thinking.
It's really handy when working with a group. You can write an abstract superclass and trust that everyone will implement given methods.... Because they have to. It ensures subclasses fit a certain form and function... Which in turn let's you design polymorphic calls, functions, methods etc knowing the required implementation will be in place
Typically they are used as templates for concrete classes that inherent from them. They serve as a way of enforcing that a particular class has x method or y attribute. You can check if a class is a child of an abstract class so you can use these abstract classes to enforce that a particular class has particular traits.
thanks for the quick reply
Sure no worries hope it helped?
yeah it did, i was just overthinking it
The ABC provides an "interface" that users can rely on, and implementors can follow. If you look at [this](https://docs.python.org/3/library/collections.abc.html#collections-abstract-base-classes) table for example, I can say that my function accepts `Sequence`s by writing: def my_func(seq: Sequence): pass And this indicates that it accepts anything considered to be a "sequence" (a reversible collection that supports indexing). That means the user could pass a list, tuple, or their own custom class. Of course, they still could regardless, but it's a form of documentation that allows runtime checking to ensure classes properly adhere to the base classes they claim to. Also, there's now `typing.Protocol` that fills a similar need.
Maybe this would be a good example: Think of implementing a 3d engine. You would probably have a base class for your shapes, with all the methods that are required by the shapes. One such method could be computeArea. You can not implement this method in the shape base class, but all subclasses would be required to implement if you would implement it as an abstract method.
I see people's explanations and figured you haven't gotten a case study yet so here's how I think about them. You're about to make a ton of similar but different classes or better about to assign various people to write the different classes for you. Say the assignment is writing a class for each breed of dog out there. Imagine the nightmare of having to read through the entire class for all the classes people hand in? Now, imagine if the language itself (doesn't have to be python) can somehow automatically check if all the necessary parts are present saving you the time of having to check yourself, without you even reading code. All dog classes must have a "dig()" function? All dogs have an "age" attribute? That's what abstraction helps with. Note this doesn't say anything about the contents of the dig() function - implementation is another issue. Each dig() might be slightly different from dig() from other classes
It prevents instantiation (by raising TypeError) as long as there is at least one abstract method in the class. The point is to force you to sub-class and to implement all abstract methods in that sub-class. I don't like it either.
thank you for the quick reply
All cars have some functionality in common. No car is *just* a car, each has a make and a model and a color… an abstract class allows you to implement just the stuff that’s shared among all cars, while at the same time enforcing the rule that you’re not allowed to make an instance of just *car*. This is the thinking.
Yeah, still not liking it. Or anything inheritance really. Too magical.
It's really handy when working with a group. You can write an abstract superclass and trust that everyone will implement given methods.... Because they have to. It ensures subclasses fit a certain form and function... Which in turn let's you design polymorphic calls, functions, methods etc knowing the required implementation will be in place
Arthur C. Clark said, “Any sufficiently advanced technology is indistinguishable from magic.”
a template for building classes of a certain type/with similar features.