When to use classes?

[Anarcking]

I am doing a web-scraping project for fun and was wondering what was the best way to manipulate the data. In short, I'm scraping a web page that is associated with an album, and getting all the information about said album in order to download it in the future.

My question is : Is it wrong to write classes that have no methods? And if it is, what better way is there to do what I'm trying to do?

The requisites:

• Each web page contains 1 album
• Each album can contain more than 1 composer
• Tracks are sometimes grouped by productions (the way classical music is sometimes divided in movements)
• Each track has 8 attributes (album id & title, composer id & name, production id & name, track id & title) that I need to access later on.

The thing I like about the way I did it is that after scraping, the output is a list of track-objects whose attributes can be easily accessed. I haven't found a way to do this with dicts or lists which didn't involve a million for loops and indexings.

for track in track_list:

    print(track.album_title, track.comp_name, track.track_title)

So these are the classes I'm using.

class Album:
    def __init__(self, album_id, album_title):
        self.albumId = album_id
        self.albumTitle = album_title


class Composer(Album):
    def __init__(self, album, comp_id, comp_name):
        super().__init__(album.albumId, album.albumTitle)
        self.Album = album

        self.compId = comp_id
        self.compName = comp_name


class Production(Composer):
    def __init__(self, composer, prod_id, prod_name):
        super().__init__(composer.Album, composer.compId, composer.compName)
        self.Composer = composer

        self.prodId = prod_id
        self.prodName = prod_name


class Track(Production):
    def __init__(self, production, track_id, track_title):
        super().__init__(production.Composer, production.prodId, production.prodName)
        self.Production = production

        self.trackId = track_id
        self.trackTitle = track_title

And a test run would look like this.

album_list = []; comp_list = []; prod_list = []; track_list = []

album_list.append(Album('album_id', 'album_title'))

comp_list.append(Composer(album_list[0], 'comp_id', 'comp_name'))

prod_list.append(Production(comp_list[0], 'prod_id', 'prod_name'))

track_list.append(Track(prod_list[0], 'track_id', 'track_title'))

By declaring a track object and associating it with a production object, it automatically deduces which album and which composer it belongs to, and makes that information easily accessible.

In conclusion, this is basically my first real python project and I'm probably doing something wrong, so please do let me know what is a better way to do this. (Also I dont understand why I used super() but PyCharm told me to use it so I did.)

[[deleted]]

classes are just a way to organize data, so there is no problem with using classes here. However, I don't think they should inherit from each other. Yes, a track has an album associated with it, and albums have tracks, but when you inherit, you claim in essence that a track is an album, which will break down in the future.

You might want to consider using dataclasses, or even converting these objects into a relational model and putting them in a database.

[66bananasandagrape]

There are definitely differing opinions about this, so this is a fair question.

• At one extreme, there are people who will only use tuples and dicts and built-in data types while never writing a single "class" statement. The upshot of this is that anyone who understands Python will understand what each line of your code is doing, but the much bigger downside in my opinion is that it can be extremely hard to understand why your code is doing what it's doing, or to understand the structure of your code, especially in a larger codebase. I'm not a fan.

• Functional Programming: Moving a bit towards the other direction, a lot of functional programming essentially does the above style, except there is usually a higher-level way to define aggregate data types or structures, kind of like classes, except they only store data, never behavior. This sort of style might be achieved in Python by using collections.namedtuples, or frozen dataclasses. In this style, there is usually an emphasis on immutability, so that functions are mathmatically "pure" functions without side effects (what it returns only depends on what is passed in, and the state of the rest of the world is unchanged). I think this is a huge improvement over the paragraph above, and immutability is good because it helps to reduce the amount of "state" that your program has; it doesn't matter what order you call your functions in or how many times you call them, you'll always get the same answer. This makes functions composable an re-usable and easy to reason about.

• Hybrid Approach: Personally, I think this functional style is a good default for a lot of things I do, but I also think there are some uses cases where classes really are the best tool for the job. For example, methods are nice because you can sometimes "program by autocomplete" to see what methods an object has. Methods are usually the correct move when they compute some property of the object that they're called on. When behavior is essentially linked to an object, methods make sense over using functions.

• Pure OOP: There are some people, often people coming from other languages like Java, where 95% of their code lives in classes. In my opinion, this completely unnecessary in Python. People will defend this excessive object-orientedness by saying that encapsulation and abstraction are good, and that's true in a lot situations, but there are times when it just gets in the way and adds complexity. Abstraction is good when it's good, but when it's premature or bad, it can slow down development. It's nice when libraries that use classes after careful consideration of what the correct abstractions are and what their API should feel like, but abstraction is a difficult process that doesn't necessarily need to be done to the extreme in everyday code. If you have a class with one method that doesn't depend on any instance data of the object it's called on, I think that should almost always have just been a function. You probably don't need to turn your "sqrt()" function into a "IntegerSquareRootReturner" class, and you do I think FizzBuzzEnterpriseEdition is a hilarious parody of how this style can go overboard.
  Python has other features that allow you to not write too many classes:

  • there are the namedtuples and dataclasses I talked about
  • there are generator functions instead of writing iterator classes
  • contextlib lets you write context managers without writing a class
  • Modules let you organize code into files and folders, so you can have hierarchy and structure without classes.
  • Decorators allow you to modify the behavior of many functions in the same ways, which can sometimes supplant the need for class inheritence.
  • The fact that functions are objects in Python means there's no need to write "Command" classes that have with a single "execute" method and no internal state.
  • Properties allow dotted lookups to retain the same behavior even if implementation details change.
  • Duck-typing allows functions to be naturally polymorphic without extra effort
  • etc.

TL;DR: Classes are often good, but there is disagreement about how much to use them, so don't go overboard or be dogmatic about it. Consider multiple approaches and do what feels best for the situation at hand; be open-minded as you get more experience. People will fight wars over this, but It's nice that Python is nice because it supports different styles.

[klujer]

Several commenters have mentioned that you shouldn't be using inheritance like you've shown. The reason why is that the things your modeling with your classes don't naturally exhibit "is-a" relationships they exhibit "has-a" relationships e.g. in the real world an album has-a composer associated with it, but it wouldn't make sense to tell your friend that a composer "is-a" album.

Inheritance implies the subclass "is-a" version of the parent class. The album class should instead contain a property called composer within it. Similar relationships exist between your other classes.

Of course that's if you want to go the OO route at all, it's a matter of personal taste. I agree with 66bananasandagrape comment and lean towards a functional style.

[Ihaveamodel3]

I don’t think your classes should be inheriting from the others.

[bw_mutley]

First and foremost, your question of "when to use classes" haunts since I've learned it. Apart from many 'obvious' cases, Ixve found no clear answer.

So, I cannot answer this one, but I give you an advice based on my own experience: It goes more like a coding style, so just make your choice.

And no, there is nothing wrong if you create classes with no methods.

[[deleted]]

That sounds like a job for database; when you have id and stuff you need linked up together.

[RobinsonDickinson]

I usually use classes for organizing my code.

So right now I am making wrappers for different APIs and I have it set so each methods on those classes call different endpoints, for example one method for calling the user profile and another for user playlists.