Some ideas and opinions on the anti-oo Theory

Source: Internet
Author: User

Preface:

During study-Erlang, I occasionally see an attack on "oo ".Article, Instantly trigger a bit of your feelings, write it down, as a point of personal opinion learned for N years "oo" & summary.

 

For the original article address, see:

Http://erlang-china.org/misc/why_oo_sucks_cn.html

The author wrote four major things to criticize "oo", probably because he was disgusted with everything.

--> My understanding is: in this case, various languages have their own design ideas and solutions. If Erlang and OO are also hardened together, it can only be a "Miscellaneous", but it makes it hard for people to understand the core and essence of Erlang. of course, it cannot be ruled out that, after a few years, a language can be used to gather the power of the family and solve most of the problems. However, it seems difficult now, that's what happened N years later. You don't have to rush for immediate success. Now you're thinking about "the power of the family"

The author objected to reason 1: In OO ,"Data Types and methods should be bound together"

--> In my understanding, in some cases, ype and method should not be put together, because in many cases, different references may be generated for a data source, so that the method is different. however, it is not "recommended" in OO, which is based on the core idea of individuals rather than oo. in actual OO programming, separating data from method is also a common practice. only oo does not provide specific provisions for this, so that due to personal habits or specific casesProgramHard to understand, but it has nothing to do with OO.

The author objected to reason 2: In OO ,"Everything must be an object"

--> This is just a Convention. Some independent functions do not have the "object" logic, but you can organize them into an object for ease of use. (avoid name conflicts, etc .) there are no obvious disadvantages in this regard. At least so far, I have not found any serious problems.

The author objected to reason 2: In OO ,"In an OOP language, data type definitions are distributed to any location."

--> The same point-1, oo does not have relevant provisions, leading to unclear datadefine in some cases, causing misunderstanding. my understanding is also the same as that of point-1. If you think it is necessary, put datadefine in one place. Of course, this may not happen because of my habits, however, this is not the problem to be solved by the OO core. Like Erlang, it is not considered in terms of the efficiency of developing large programs.

The author objected to reason 2: In OO ,"The object has a private State."

--> This opposition is rather stubborn. The object's own State is determined by the corresponding logic. If you do not want to expose the object to external users, or you should not concern external users, this is also necessary, especially when developing large-scale programs, you do not have to understand the specific processing behind all the APIS, but simply care about its interfaces is a huge benefit. likewise, an object may be a part of processing logic. It is also a huge benefit for users to understand all its internal details and focus only on what is exposed.

 

Postscript:

When looking at the problem, we often have in-depth discussions on a specific issue and thoroughly studied it. This is good, but we are sorry to ignore its responsibilities and functions, the discussion in the dialogue on the two worlds system may cause us to think deeply: (The following is a reference)

"In any case, von noriman's design indeed brought an uncertain curse to the computer industry in the future. Today's countless talented programmers are eager to think about parallel computing, which is actually a very humorous question-how to implement parallel programming on a machine originally designed to prevent parallel computing? "

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.