Is it good to use functions in OOP?

Question

I am new to programming. I recently read that:

Your program should have almost all functions encapsulated in either functions or class methods

It seems like I should not have both functions and methods. I also read that methods should be short and simple.

Well, I recently made a small program that downloads images from blogs. I used OOP classes and approach because I need to inherit certain things.

However, since the methods must be short and do one thing, my program cannot do much. My question is: if I try to use a clean OOP approach, how can I avoid writing functions?

My script follows basically this scheme:

class Tumblr(object): def __init__(self, user): self.user = user def get_posts(self): """Use tumblr api to return a user posts.""" return client['blog']['posts'] def parse_images(self): """Returns images.""" images = [] for post in posts: if 'image' in post: images.append(post['image']) return images def parse_videos(self): """Returns videos.""" def main(): # this is a function, and thus not OOP? 

I also have other classes for different website APIs, as well as the Downloader class, which actually downloads files to disk and to the corresponding directory. The problem is that now I have all these isolated classes and methods.

I thought about creating a main function that can also use other functions, but then again, I don't think this is the correct OOP.

How can I get a job without writing functions? (The textbooks I read said that functions should not be used in pure OOP if I use methods.)

Answer 1

Fur, no.

The presence of the main() function is so ubiquitous and required in some languages ​​that using it as a hook for launching in order is something somewhere that should say "go". Although, it is pythonic to implement it as

 class YourObjectHere(object): ###blahblahblah your code here ... ... def main(): MyObj = YourObjectHere(*args, **kwargs) OtherObj.do_stuff_with_obj(MyObj) #etc etc etc ... ... if __name__ == '__main__': main() 

Among other reasons, because it allows you to reuse the code as a module and import it, without forcing things to run every time.

Stupid agreement is consistent, of course, but it is stupid, first of all. Do what you need to do, but look at the language to make sure that you are not just duplicating efforts. See https://www.youtube.com/watch?v=o9pEzgHorH0 for a great video about writing a class is a bad idea - the first rule is usually if the object has two methods and one of them is __init__() He probably shouldn't be a class.

Answer 2

No need to write classes when functions are enough. Paraphrase from Zen of Python ;

• Simple is better than complex.
• Practicality exceeds purity.

In Python, you can use many programming methods; procedural, object-oriented, functional. Everyone has their own strengths and weaknesses. But everyone has their own abilities.

If you are trying to create a purely object-oriented solution to a problem, this may be a sign that you are Doing It Wrong and that objects are not the best solution for this particular problem.

You should use the method that best suits this problem.

Jack Diederich PyCon's "Stop Class Writing" presentation contains some good examples. The obvious lesson was that if your object has two methods, one of which is __init__ , it really is a disguised function.

Answer 3

Your program should have almost all functions encapsulated in functions or class methods

Pay attention to the word "almost." This is your loophole right there.

This rule that you specified is a "rule". It is an offer to follow as much as possible, and as long as it makes sense. If you sometimes have to make exceptions, this is normal, this is not the end of the world. And that’s why the word “almost” is.

And if the word "almost" was not there, general statements like this will never be 100% true, there are always justified exceptions. This offer wants to put you on the right path, it really does not mean that you should follow it religiously for 100%.