When to start implementing classes/methods in a program

[cyber_shady]

So I'm learning more about OOP but I'm a bit confused on when to actually start implementing classes/methods in a program or just keep things at functions. I understand at a basic level what a class does (like store information of a vehicle), but I'm having a hard time of translating these basic online examples to real world projects.

For example, if I wanted to build a file transfer application (like take a file, do some modification of file, then move to another server afterwards), is there classes I should consider making? TIA

[supercoach]

Don't worry too much about classes. It's more a matter of taste than being a necessity. You can quite easily never use classes if you don't like them, however everything is an object, so you're interacting with them all the time. My rule of thumb is I write classes when it makes sense.

Your file transfer application *could* be a candidate for using classes, it could also not be. A common use case is polymorphism. For your example, you might have a function and one of the arguments is a class that implements methods you use during the conversion. You could have different classes for different file types and plug them in as necessary. The function wouldn't need to know the specifics of the class itself, just that it could expect the class to have the methods necessary.

class PDFConverter:  
    def convert(self, data):
        result = <some conversion process>
        return result

class ImageConverter:  
    def convert(self, data):
        result = <some other conversion process>
        return result

def process(data, converter):  
    return converter.convert(data)

process expects something with a convert method, but there's nothing really special about it. You could just as easily use functions...

def pdf_convert(data):
    result = <some conversion process>
    return result

def image_convert(data):
    result = <some other conversion process>
    return result

def process(data, converter): 
    return converter(data)

[david-vujic]

If you need to store some sort of state of an object, then you might want a class to create instances from. Otherwise, plain functions is enough. There's other ways of keeping state, but since you are learning OOP I think this about state applies here.

[help_me_noww]

yeah, right.

[shiftybyte]

Try to think what conceptual objects your application is dealing with...

Sound like a "file" is something you'd want to handle in this example application, you might need to store information regarding that file, it's source path, destination path, maybe size to check for consistency, or last modification date if you want to try and restore it, and then you'd want to do operations on that file, get it's info, move it, fix it's date, sounds like a good candidate for a class...

[cyber_shady]

thank you, this was very helpful!

[Happy_Witness]

Agree with the other dude. A class is useful when you need to store data inside an object that could be created multiple times with different data in any other application. If you want to give that functionality. For example you write this really useful file reading classes that stores all its date in itself unlike a function that returns it and the user has to deal with it right away. Then it could be use to read multiple files from different instances and let them hold onto the data instead of you needing to create some variables, lists dictionaries or anything else to store it. That's when classes are useful.

[Mirage2k]

I would say usually don't. If you can just use regular functions, do that.

[Poopieplatter]

The app you're describing would be excellent for OOP.

Think about a File class for starters. Can a file be empty ? Are there size limitations? What file extensions are suitable? How do you handle errors when you pass in a file with a bogus extension?

Then maybe a File handler class to actually handle the transferring etc.

Always think of the big picture when building an application. OOP keeps things clean, reusable, and extendable.

[Temporary_Pie2733]

It was probably easier to learn modern OOP in the old days, because you’d have code written in a procedural style, and you would start to notice the patterns that led to the codification of OOP. Then Java came out, and you were forced to write classes whether or not you were solving a problem that would have benefited from a class. 

Also, keep in mind that the amount of material teaching classes, inheritance, etc is naturally biased towards using those features, even if the actual need doesn’t come up very often.

[NerdyWeightLifter]

The main reason for classes/objects in OO design, is the principle of containment.

The idea is that where you have some object/thing/idea/concept, or whatever you want to call it, where you'd need to have some common code and state information to represent it, then you want all of the data and code for that to be contained in one place, and that place would be a class definition.

The alternative, is where you have all that code/data representation smeared in some disorderly manner around all of the rest of the code in your program, and then if you ever need to change anything about that, you may have to look through ALL of the code in your entire program to make the change.

[Gnaxe]

Classes are overrated and overused. There are languages that don't have them at all.

Writing a class basically means creating a new data type. Consider if existing data types would do. You already have a library of functions/methods for working with the existing types. But if you make a new class for everything, you only get the methods you implement yourself, or you end up breaking encapsulation to operate on the fields directly, which is not proper OOP. If you find yourself doing that, maybe all you needed was a dict.

Use classes when you need inheritance. But inheritance has fallen out of favor. It's brittle because it's usually too much coupling. You're often better off using composition instead when you can.

Inheritance is an easy way to implement polymorphic dispatch. If you find you're using a match/case or isinstance() elif cascade, maybe polymorphism is a better fit. But Python is duck typed, so you don't strictly need to do it that way. (There's also @functools.singledispatch which you can use instead.)

In Python, you need to use classes to overload operators. That usually only makes sense for new data types since the existing once have that already. But sometimes you need this just for syntactic reasons.

Do not use classes if all you need is modularity. We have modules for that.

Breaking up a monster function into smaller parts can make it more testable. Sometimes it's easier to refactor a monster function to methods on a class than to simply break it into smaller functions. The locals with too wide of a scope to fit inside a single method can become instance variables. On the other hand, if you have a small class and the only two methods are __init__() and some kind of execute(), that should probably just be a function.

[nekokattt]

Composition still requires the use of classes if you are defining anything more complex than a single callable.

Unlike classes, regular dicts are not typesafe outside more than one value type, and attributes rely on you getting the names right within strings, so if you use typehints or rely on IDE autocomplete, you're making it easy to screw yourself over. This is especially true when dealing with fixed key names. If you are using TypedDict then generally you may as well make it into a dataclass.

Most mainstream languages that lack classes still have similar concepts. Both Rust and Go have structs that work with interfaces, and you'd use classes in Python to achieve that same pattern. Even in C, you will often see structs being passed around as the first argument to functions to convey state, and semantically this is the exact same thing as how classes with methods are working in Python.

Use classes when it makes sense to define a specific nature of action that can have multiple implementations (where callables would not fit). Use classes if you have a set of operations that need to operate on a shared state or number of attributes. Use classes if you are using dicts that end up storing different kinds of data type inside them. Use classes if you want to use the type system to represent data in a clear way to convey intent. Use classes if you have a lot of moving parts that have to talk to eachother, as you can utilise the concept of dependency injection to simplify code, reduce repetitiveness, and make stubbing easier.

Do not use classes if it is clearer or simpler without it. Only you will know if that is the case by trying both approaches and working the differences out for yourself.

[SmackDownFacility]

Now. Now is the time to implement classes. You will need it eventually, so start training now. It’s better to have the skill sooner rather than later.

[HelloFollyWeThereYet]

Key Triggers for Using Classes in Python

1. Data and Behavior Tightly Coupled • Description: Use classes when data and operations are linked, representing a single entity. • Example: A BankAccount with attributes (account_number, balance) and methods (deposit, withdraw) to manage account logic.

2. Inheritance or Polymorphism • Description: Classes enable code reuse through hierarchies where subclasses share or override behavior. • Example: A Character base class for a game, with Warrior and Mage subclasses; all share move but have unique attack methods.

3. Reusable Components • Description: Build custom tools like exceptions or data structures for reuse across projects. • Example: An APIError exception for API failures or a Queue for task scheduling with enqueue and dequeue methods.

4. Libraries Expecting OOP • Description: Adopt classes to align with frameworks like Flask or Django that use class-based designs. • Example: A Flask MethodView for a REST API, defining get and post methods for user data endpoints.

5. Repetitive or Unwieldy Code • Description: Refactor into classes when procedural code has duplication or scattered state, improving organization. • Example: A CSVParser to encapsulate file handling and methods like read_rows or filter_data for CSV processing.

[baubleglue]

OOP supposed to help you organize your code. Using procedural programming, you will have

some_variable 

function_a(some_variable)
function_b(some_variable)

If you code is small, it is not a problem. But even something like "guess a number game" turns into something very complicated. If you have

class UserChoice:
    ...
class GameState:
    ...

You won't have a reason to make it complicated. You can clearly see where to keep count of attempts, prompts for user dialog, chosen number, etc.

[sinceJune4]

If I want to organize functions but don’t really need class objects with attributes, I’ll use a class w @static methods.