Shulou(Shulou.com)06/03 Report--

In view of whether the object-oriented in Python is meaningless, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Recently, a lot of people have been attacking object-oriented, and while I don't think there is anything wrong with object-oriented itself, I don't think it's necessary, at least in Python.

1. There is no need to use object-oriented

For example, the following code does not need to use object orientation at all.

Class ApiClient: def _ _ init__ (self, root_url: str, session_cls: sessionmaker): self.root_url = root_url self.session_cls = session_cls def construct_url (self, entity: str)-> str: returnf "{self.root_url} / v1 / {entity}" def get_items (self Entity: str)-> List [Item]: resp = requests.get (self.construct_url (entity)) resp.raise_for_status () return [Item (* * n) for n in resp.json () ["items"]] def save_items (self Entity: str)-> None: with scoped_session (self.session_cls) as session: session.add (self.get_items (entity)) class ClientA (ApiClient): def construct_url (self, entity: str)-> str: returnf "{self.root_url} / {entity}" class ClientB (ApiClient): def construct_url (self) Entity: str)-> str: returnf "{self.root_url} / a/special/place/ {entity}" client_a = ClientA ("https://client-a",session_cls) client_a.save_items (" bars ")

Object orientation is used here because we want to bind root_url to an object and don't want to pass sessionmaker every time. We also want to use inheritance to access a method in the middle of the call.

But can it be achieved only through data transfer and functions?

@ dataclass class Client: root_url: str url_layout: str client_a = Client (root_url= "https://client-a", url_layout=" {root_url} / {entity} ",) client_b = Client (root_url=" https://client-b", url_layout= "{root_url} / a/special/place/ {entity}",) def construct_url (client: Client Entity: str)-> str: returnclient.url_layout.format (root_url=client.root_url, entityentity=entity) def get_items (client: Client, entity: str)-> List [Item]: resp = requests.get (construct_url (client, entity) resp.raise_for_status () return [Item (* * n) for n in resp.json () ["items"]] def save_items (client: Client, session_cls: session_cls Entity: str)-> None: withscoped_session (session_cls) as session: session.add (get_items (client, entity)) save_items (client_a,session_cls, "bars")

We must pass Client and session_cls at any time.

But what does it matter? The amount of code is even 10% less. The code written in this way is easy to understand and does not require the use of object orientation.

Some people call this writing "function bag". That is, the whole code consists of typed data and a large number of module-scoped functions.

What about global variables? You can refer to this article (https://leontrolski.github.io/sane-config.html), which reuses config or db's session throughout the life cycle of the application

What about interfaces and abstract classes? In fact, you don't need them, just write the code. To be fair, it is only after Python has type tagging that the function bag style begins to show its real charm.

What about impure functions?

If you want to use pure functional programming, you may want to write pure classes and then use impure "adapter" instances to do some processing: getting-the-current-datetime/API-calls/talking-to-the-db/other-impure-stuff. That's a good idea. In fact, you can directly use freezegun, responses and other methods to avoid a lot of trouble.

2. Exception

But there are some exceptions:

You may have noticed that @ dataclass is added to the refactored code, and they are just record types. Python 5 can support these directly without the need for the "general" class.

It's okay to use subclasses of Exception. Use try:... Except SomeClass:... basically forms a hierarchy, but it doesn't matter, as long as it doesn't get too complicated.

Enum, as above, are perfect for Python.

In rare cases (at least rarely in application development), you may come up with a very useful type and use it everywhere, just like pandas.DataFrame/sqlalchemy.Session. But in general, don't kid yourself, don't kid yourself that we're building great applications. Modesty makes one progress.

3. The disadvantages of object-oriented

Although I said at the beginning of this article that I don't think there is anything wrong with object-oriented itself, in fact, I still feel that object-oriented is not only unhelpful, but also often confuses the problem and encourages some bad practices:

Object-oriented encourages you to modify data. The function bag is very opposed to modifying parameters. If you don't believe it, you can try, but don't be angry.

Object-oriented is just a returned global variable. You can't share data between functions, and self forces you to write functions that are easy to test in a smaller state space.

Mixing data and functions can make serialization more difficult, and serialization is very useful in today's popular REST API situations.

Object-oriented brings a crazy inheritance system, and there is a lot of discussion about this topic.

Most importantly, object-oriented does not have any added value, it only makes it difficult for you to concentrate on solving the problem and make it more difficult to browse and understand the code.

This is the end of the answer to the question about whether the object-oriented in Python is meaningless. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.