“Lập trình hướng đối tượng” là sao?

Nhiều người (đa phần là sinh viên hoặc những người mới tiếp xúc với lập trình) thường cảm thấy sợ khi nhắc đến khái niệm “HƯỚNG ĐỐI TƯỢNG”, vậy thì nó là gì?

Sau đây là theo quan điểm của một con gà công nghệ như tôi.

LẬP TRÌNH HƯỚNG ĐỐI TƯỢNG (OOP – Object-oriented programming)

Chúng ta sẽ tách ra làm 2 vế: LẬP TRÌNHHƯỚNG ĐỐI TƯỢNG.

  • Lập trình: Quá trình chúng ta ra lệnh cho máy tính làm những việc mà chúng ta muốn bằng cách giao tiếp với nó thông qua một ngôn ngữ nào đó (ngôn ngữ lập trình).
  • Hướng đối tượng: Đối tượng là những gì có xung quanh chúng ta.

Như bạn cũng biết thì máy tính được phát minh ra để giải quyết những vấn đề thực tế trong cuộc sống mà con người khó hoặc không thể làm được, ví dụ như tính nhiều phép toán cùng một lúc chẳng hạn.

Lập trình hướng đối tượng tức là dùng ngôn ngữ lập trình để giải quyết các vấn đề trong cuộc sống.

Ví dụ viết một chương trình tính toán lãi suất ngân hàng, thì những con số chính là đối tượng mà chúng ta sẽ phải làm việc với nó, và nhắc đến lập trình thì hầu như chúng ta đều phải làm quen với những con số, những phép toán. Cho nên người ta mới nói để trở thành một lập trình viên giỏi thì cần phải giỏi toán, nhưng các bạn lưu ý một điều là dở toán không có nghĩa là không thể trở thành một lập trình viên giỏi.

Thật ra nó chẳng có gì ghê gớm cả, các bạn hãy từ từ thưởng thức nhé, nó chỉ là bước đầu thôi. Chúc các bạn thành công!

Huy Nguyen

Why I use the Opera browser?

Some awesome features are available at this time on Opera browser (based on Chromium)

Free VPN: This enable you to access to blocked site in your country.

Screen Shot 2017-04-01 at 01.06.49


Built-in ad block: We don’t need to install ad-block extensions anymore.

Screen Shot 2017-04-01 at 01.08.43

Some other cool features are the reason I changed my default browser to Opera: Battery saver, cool animated background on speed-dial screen, a very nice left side bar where we can easily access to some great features.

Wait for what? Let’s check it out!

The Ten Commandments of Egoless Programming

1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.

2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.

3. No matter how much “karate” you know, someone else will always know more.Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.

4. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.

5. Treat people who know less than you with respect, deference, and patience.Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.

6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.

7. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.

8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don’t take revenge or say, “I told you so” more than a few times at most, and don’t make your dearly departed idea a martyr or rallying cry.

9. Don’t be “the guy in the room.” Don’t be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.

10. Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

(The Psychology of Computer Programming was written way back in 1971)