don編程

㈠ C++語言是什麼啊

一種編程語言~

C++，這個詞在中國大陸的程序員圈子中通常被讀做「C加加」，而西方的程序員通常讀做「C plus plus」，它是一種使用非常廣泛的計算機編程語言。C++是一種靜態數據類型檢查的，支持多重編程範式的通用程序設計語言。它支持過程序程序設計、數據抽象、面向對象程序設計、泛型程序設計等多種程序設計風格。

貝爾實驗室的本賈尼·斯特勞斯特盧普（w:en:Bjarne Stroustrup）博士在20世紀80年代發明並實現了C++（最初這種語言被稱作「C with Classes」）。一開始C++是作為c語言的增強版出現的，從給C語言增加類開始，不斷的增加新特性。虛函數（virtual function）、運算符重載（operator overloading）、多重繼承（multiple inheritance）、模板（template）、異常（exception）、RTTI、名字空間（name space）逐漸被加入標准。1998年國際標准組織（ISO）頒布了C++程序設計語言的國際標准ISO/IEC 14882-1998。遺憾的是，由於C++語言過於復雜，以及他經歷了長年的演變，直到現在（2004年）只有少數幾個編譯器完全符合這個標准(這么說也是不完全正確的，事實上，至今為止沒有任何一款編譯器完全支持ISO C++)。

另外，就目前學習C++而言，可以認為他是一門獨立的語言；他並不依賴C語言，我們可以完全不學C語言，而直接學習C++。根據《C++編程思想》（Thinking in C++）一書所評述的，C++與C的效率往往相差在正負5%之間。所以有人認為在大多數場合C++ 完全可以取代C語言(然而我們在單片機等需要謹慎利用空間、直接操作硬體的地方還是要使用C語言)。

㈡ 什麼叫編程函數他有什麼作用c++的結構是怎樣的

我下面說的就是函數的定義，如果你不能完全理解的話我建議你先看看下面的C語言結構，不然別人再怎麼給你解釋你也聽不明白：（

在某個變化過程中，有兩個變數x、y，如果給定自變數x一個值，那麼應變數有且只有一個變數與之對應，那麼我們稱y是x的函數。

人們對C++有許多不同的看法，保守的C++程序員堅持用其他語言創建COM組件，他們認為只有真正的程序員使用C++。另一方面，VB程序員認為C++是一種很難掌握和使用的語言，沒有必要增加編程時間和進行艱難的嘗試。java程序員認為他們比C++程序員強，因為James Gosling(Java的發明者)吸收了許多語言(包括C++ )的優點發明了Java，本章和下一章的目的就是消除對C++的偏見和錯誤概念。

本章集中介紹用C++ 建立伺服器組件，不講述C++語言，如果想學C++ ，請參閱Ivor.Horton著的《Beginning Visual C++6》，Wrox 出版，書號為ISBN 1-861000-88-X。

本章的主要內容有：

? C++簡史。

? 使用C++原因。

? 從VB移植到C++。

? ATL、STL和MFC介紹。

? 建立一個COM組件。

? 錯誤處理與調試。

更重要的是應該記住，現在，不只是在用C++建立組件，可以使用Visual C++中可用的任何工具，使得建立過程更加容易。先從C++的起源談起。

17.1 C++語言

在決定是否使用C++語言之前，最好是搞清楚這種語言的實質，讓我們看一下C++的歷史和現狀。

17.1.1 C++簡史

剛開始形成的是C語言，那些想建立更快更有效的代碼的程序員非常欣賞C語言，有一位名叫Bjarne Stroustrup的人卻不滿足於僅僅是生產快速代碼，他想創建面向對象的C語言編程。他開始對C語言的內核進行必要的修改，使其能滿足面向對象模型的要求。C++從此產生。

Bjarne Stroustrup是C++的最初設計者和實現者。它自誕生以來，經過開發和擴充已成一種完全成熟的編程語言。現在C++已由ANSI、BSI、DIN、其他幾個國家標准機構和ISO定為標准。ISO標准於1997年11月4日經投票正式通過。

C++標准演變了許多年。C++模板是近幾年來對此語言的一種擴展，模板是根據類型參數來產生函數和類的機制，有時也稱模板為「參數化的類型」。使用模板，可以設計一個對許多類型的數據進行操作的類，而不需要為每個類型的數據建立一個單獨的類。標准模板庫(Standard Tempalte Library，STL )和微軟的活動模板庫(Active Tempalte Library，ATL )都基於這個C++語言擴展。

C++標准可分為兩部分， C++語言本身和C++標准庫。C++標准庫對於Visual C++是相當新的，實際上微軟只是在發布Visual C++ 5.0時去除了一些「bug」。標准庫提供了標準的輸入/輸出、字元串、容器(如矢量、列表和映射等)、非數值運算(如排序、搜索和合並等)和對數值計算的支持。應該說， C/C++包含了相對少的關鍵字，而且很多最有用的函數都來源於庫，C++標准庫實現容器和演算法的部分就是STL。

STL是數據結構和演算法的一個框架，數據結構包括矢量、列表和映射等，演算法包括這些數據結構的查找、拷貝和排序等。1994年7月，ANSI/ISO C++標准委員會投票決定接受STL為C++標准庫的一部分，這個建議是根據Alex Stepanov、Meng Lee和David Musser這三人的編程和軟體庫研究提出的。STL的產生是為了滿足通用性的設計目標，而不是為了提高性能。

那麼微軟對C++標準的態度怎什麼樣？微軟運行VC++與Plum-Hall C++，想比較得到的分數在92%和93%之間。為什麼不是100%的一個原因是跟蹤這個標准並同時建立一個編譯器比較困難，微軟也考慮了對現有編碼兼容的重要性，有時他們不得不偏離標准以保持這個兼容性。

17.1.2 使用C++的原因

應該有充分的理由使用C++創建伺服器組件，而不只是為了給上司一個好印象才使用C++。如果以前沒用過C++，你必須要盡力學習。

1. 性能

性能有個兩方面，演算法速度和機器代碼效率。一個演算法可以定義為數據通過系統的概念化的路徑，它描述一些點，在這些點上，數據能夠被操作並可轉換產生某個結果。例如，一個演算法定義為獲取一個字元串，計算字元串中的字元個數，並作為結果返回的過程。演算法與

語言是獨立的，所以在編程之前必須設計演算法，編寫一個快速程序的第一個步驟是設計良好的演算法，能以最少的操作步驟得出問題的答案。第二個步是選擇語言，這也影響程序的速度。

從性能的角度考慮，用匯編語言編寫程序是最佳的選擇，它是計算機能理解的自然語言。但是，幾乎沒有人用匯編語言編寫完整的程序，因為這樣做極其乏味。另一個最佳的選擇是C語言。然而，由VC++提供的所有工具都產生C++，而不是C。使用VC++的向導可以生成大量的使用代碼，而不必人工地編寫代碼。從編寫程序的難易程度和程序的性能綜合考慮， C++是最佳的選擇。

C++性能良好，因為它被編譯為機器代碼。對於VBScript和Java等語言，代碼在運行時由程序解釋，而且每次運行程序時都要將代碼轉換為機器碼，這樣做效率比較低，不僅僅是已編譯過的C++程序運行得較快，而且微軟C++編譯器已存在多年。這意味著微軟的編譯器程序員已經把許多優點集中到編譯器上，以致於它能產生非常高效的機器碼。因為C++是編譯語言，而且非常自然，比VB更接近機器代碼，所以由C++編譯器產生的代碼一定比VB的編譯代碼效率更高。

2. 錯誤處理

一個好的程序與一個偉大的程序的區別就是其是否具有良好的錯誤處理支持。實際上，如果在實現中首先進行錯誤處理，而不是在最後才進行，那麼整個程序的開發和測試過程會更加完美。但是，錯誤處理只能與語言所支持的內容相一致。

VBScript具有基本的錯誤處理支持功能。在默認情況下，不能捕獲VBScript中的錯誤。每次懷疑產生錯誤時，要調用On Error Resume Next功能，並檢查Error對象。

而C++中的錯誤處理比較好，這是因為有「異常處理」，本章的後面部分將詳細介紹。

3. 最小的依賴性

正如上面所說，C++是一種編譯語言，即C++代碼在執行之前已轉換為機器碼。只要此代碼不依賴於外部的動態鏈接庫(DLL)，C++就可以在不需要安裝額外程序的情況下移動到運行同樣操作系統的其他機器和微處理器上，而移動Java程序時需要先安裝Java運行期庫。

4. 利用現有的代碼

由於C和C++已經存在許多年了，現在有許多可利用的代碼，你的伺服器組件可以使用現有的C/C++代碼或庫。例如統計庫和到老系統的C介面。

5. 最大化COM特徵

COM與C++很接近，實際上， Don Box(COM的權威)在他的《Essential COM》一書的第一章寫道：「COM就是更好的C++」。他說明了COM規范是如何從C++語言規律中產生出來的。通過理解C++，會對COM有更深的理解。

某些語言不能利用所有的COM特徵，而在C++中，幾乎可以使用所有的COM特徵。

17.1.3 不使用C++的原因

知道什麼時候使用C++是重要的，同樣，知道什麼時候不使用C++也是重要的。想像一下那些長期維護代碼的人，如果他們中沒有一些C++程序員支持C++，那麼開發者們不得不把眼光轉向另外一些他們熟悉的語言。

改變C++組件時，為了看到這些改變的結果，必須重新編譯該組件代碼，這會花費很長的開發時間。C++不能像ASP頁面代碼那樣，只使用記事本，改變代碼的一行，重新裝載而得到結果。因此，如果某些工作需要經常變化(如原型)，不要用C++。

在C++中，對一些致命的錯誤不能獲得更多的保護，寫一個使組件崩潰的代碼是很容易的。這是為了提供快速代碼而付出的代價， C++不會停下來去檢查代碼是否按設計運行能否使程序不崩潰依賴於開發者的技巧。如果在這方面花的時間較少或剛剛學習C++，最好不要使用C++。等到已經意識到C++中所有容易犯的錯誤，而且在檢測組件之前花了許多時間，才可以使用C++，如果想很快、很容易地建立一個組件，而且也不考慮該組件的執行速度，那麼使用VB吧！

17.1.4 把ASP技巧轉到C++上

學習新東西的最好方法就是利用現有的技巧。對於ASP開發者來說，已經學習了C++所要求的許多技巧，特別是，JScript語法和ActiveX或COM的面向對象編程的概念。

1. JScript

大部分ASP開發者都用JScript在瀏覽器上使用DHTML。JScript的語法與C非常相似，所以，如果懂得JScript，那麼就懂得基本的C語法。當然，只是C++語法的子集。C++有許多額外的語法來支持面向對象編程，這就是我們下一步要做的。

2. 面向對象編程

如果你在VB中使用過類(class)，則對任何COM對象和文檔對象模型(Document ObjectModel，DOM )都應熟悉，因為已經有了面向對象編程(OOP)的概念。在前面已經說過， C和C++的區別是C++支持面向對象編程。

㈢ DRY編程原則 是什麼

DRY 全稱：Don't Repeat Yourself （摘自wikipedia），是指編程過程中不寫重復代碼，將能夠公共的部分抽象出來，封裝成工具類或者用「abstraction」類來抽象公有的東西，降低代碼的耦合性，這樣不僅提高代碼的靈活性、健壯性以及可讀性，也方便後期的維護或者修改。

(3)don編程擴展閱讀：

DRY原則特指在程序設計以及計算中避免重復代碼，因為這樣會降低靈活性、簡潔性，並且可能導致代碼之間的矛盾，DRY是Andy Hunt 和 Dave Thomas's 的《 The Pragmatic Programmer 》書中的核心原則。

參考資料：DRY原則--網路

㈣ 軟體編程中高級語言有哪些

編程語言，被我們熟知的，分為2大類

低級語言，又分為匯編語言和機器語言（二進制碼語言，只用0和1）

高級語言，一般用的字母符號數字編寫

那麼高級編程語言又分哪些呢？

請看：

C

#include<stdio.h>
intmain(void){
//yourcodegoeshere
return0;
}

C++

#include<iostream>
usingnamespacestd;
intmain(){
//yourcodegoeshere
return0;
}

C#

usingSystem;
publicclassTest
{
publicstaticvoidMain()
{
//yourcodegoeshere
}
}

Bash

#!/bin/bash
#yourcodegoeshere

Java

/*packagewhatever;//don'tplacepackagename!*/
importjava.util.*;
importjava.lang.*;
importjava.io.*;
/*Nameoftheclasshastobe"Main"onlyiftheclassispublic.*/
classIdeone
{
publicstaticvoidmain(String[]args)throwsjava.lang.Exception
{
//yourcodegoeshere
}
}

Javascript

importPackage(java.io);
importPackage(java.lang);
//yourcodegoeshere

Perl

#!/usr/bin/perl
#yourcodegoeshere

php

<?php
//yourcodegoeshere

python

#yourcodegoeshere

VB

ImportsSystem
PublicClassTest
PublicSharedSubMain()
'yourcodegoeshere
EndSub
EndClass

Groovy

classIdeone{
staticvoidmain(String[]args){
}
}

Ruby

#yourcodegoeshere

Scala

objectMainextendsApp{
//yourcodegoeshere
}

個人建議：最好從C或C++開始學。可以拓展Java或者Python學習，也推薦PHP。VB學了對Microsoft宏很有幫助，其餘語言不是很推薦啊。

備註：有一種編程工具用拼圖的方式拼出程序，叫做Scratch，初學者建議試一下我也是學了這個轉C++的。但Scratch不是編程語言，切記。

㈤ Windows編程中怎樣理解「Don't call me,I will call you.」

你想想滑鼠事件和鍵盤事件是怎樣的 那他又是怎樣接收消息的? 既然 滑鼠鍵盤有響應消息,那麼同樣的USB介面也是有的.當USB介面(也就是外設)插入了U盤,那麼就像滑鼠點擊了 "確定" 按鈕一樣,那麼肯定有類似的函數和響應機制了.

㈥ 關於編程風格

<<Effective C++ & More Effective C++>>和
<<代碼大全>>兩本都是好書，看了你就懂了。

編程風格可以理解成寫程序的習慣，有好的習慣是成為高手的關鍵。

同時你會發現效率會比有一大堆壞習慣的人高很多很多。

㈦ 想學編程不知道怎麼入門，從哪學起

通常學習編程一般是有目的的， 比如想做桌面程序開發， 想做web開發，想做app，想做命令行工具等。
但是假如只是想學習編程而已，沒有明確的開發目的，想要鍛煉自己的編程能力，那麼我給出一些個人建議：
1 在linux下學習編程，比如可以安裝debian的testing系統(因為使用簡單)，從實用的角度考慮可以選擇學習python語言，如果對計算機硬體很有興趣的話可以選擇c語言。
2 找一本不太厚的書，安靜地坐下來慢慢研讀，邊讀邊動手，先把一門語言的基礎語法學會。不要選擇那種非常厚的大全類型。
3 有了一定的語法基礎知識後，嘗試寫一些簡單的命令行小程序，比如我高三時寫過自動算24的程序，或者是一些簡單的圖形列印程序
做到這一步其實算是比較容易的，大概會花掉1到3個月的時間，下一步就是提高編程能力了
4 練習編程的基本技能，比如遞歸、搜索、字元串匹配等，學習如何評估一個程序的性能，比如你的程序是O(n) 還是O(log N)的。 如果你喜歡，還可以做一些online judge的題庫，這會大大的提高編程能力。
5 多學習現有工具的使用，比如grep、find、 awk、ssh等眾多的linux工具，學習使用現有工具就是在鍛煉自己的編程能力，這也是非常重要的。
6 如果英文閱讀能力不錯，建議盡早開始閱讀英文文檔，比如使用man程序查看help，google搜索國外的資料
做到這一步，你已經是難得的開發人員了，只需要經過工作的磨練，就能成為月薪上萬的搶手貨。但是你應該還不滿足吧？ 那麼繼續
7 學習一些編程理論知識，比如KISS原則，以及比KISS還重要的 Don't repeat yourself 原則。推薦閱讀《unix編程藝術》、《程序員修煉之道》等類似書籍，同時不要忘了不斷的鍛煉自己使用新工具的能力，比如vim、make等，熟話說工欲善其事，大家都知道了
8 找准自己的方向，尋找適合自己的團隊，在團隊中發揮自己的優勢。在工作中學會客觀地思考問題，放棄你之前所學的教條主義，什麼運行性能？用戶體驗？交互設計？牛逼的演算法？這些都是你的絆腳石。 要學會根據自身情況靈活應變，懂得取捨，懂得衡量每一個決策的性價比，你的時間和金錢才是硬道理。

㈧ 有哪些和編程有關的經典語句

1. One man's constant is another man's variable.

2. Functions delay binding: data structures ince binding. Moral: Structure data late in the programming process.

3. Syntactic sugar causes cancer of the semi-colons.

4. Every program is a part of some other program and rarely fits.

5. If a program manipulates a large amount of data, it does so in a small number of ways.

6. Symmetry is a complexity recing concept (co-routines include sub-routines); seek it everywhere.

7. It is easier to write an incorrect program than understand a correct one.

8. A programming language is low level when its programs require attention to the irrelevant.

9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.

10. Get into a rut early: Do the same processes the same way. Accumulate idioms. Standardize. The only difference (!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary.

11. If you have a procere with 10 parameters, you probably missed some.

12. Recursion is the root of computation since it trades description for time.

13. If two people write exactly the same program, each should be put in micro-code and then they certainly won't be the same.

14. In the long run every program becomes rococo - then rubble.

15. Everything should be built top-down, except the first time.

16. Every program has (at least) two purposes: the one for which it was written and another for which it wasn't.

17. If a listener nods his head when you're explaining your program, wake him up.

18. A program without a loop and a structured variable isn't worth writing.

19. A language that doesn't affect the way you think about programming, is not worth knowing.

20. Wherever there is molarity there is the potential for misunderstanding: Hiding information implies a need to check communication.

21. Optimization hinders evolution.

22. A good system can't have a weak command language.

23. To understand a program you must become both the machine and the program.

24. Perhaps if we wrote programs from childhood on, as alts we'd be able to read them.

25. One can only display complex information in the mind. Like seeing, movement or flow or alteration of view is more important than the static picture, no matter how lovely.

26. There will always be things we wish to say in our programs that in all known languages can only be said poorly.

27. Once you understand how to write a program get someone else to write it.

28. Around computers it is difficult to find the correct unit of time to measure progress. Some cathedrals took a century to complete. Can you imagine the grandeur and scope of a program that would take as long?

29. For systems, the analogue of a face-lift is to add to the control graph an edge that creates a cycle, not just an additional node.

30. In programming, everything we do is a special case of something more general - and often we know it too quickly.

31. Simplicity does not precede complexity, but follows it.

32. Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis.

33. The 11th commandment was "Thou Shalt Compute" or "Thou Shalt Not Compute" - I forget which.

34. The string is a stark data structure and everywhere it is passed there is much plication of process. It is a perfect vehicle for hiding information.

35. Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers.

36. The use of a program to prove the 4-color theorem will not change mathematics - it merely demonstrates that the theorem, a challenge for a century, is probably not important to mathematics.

37. The most important computer is the one that rages in our skulls and ever seeks that satisfactory external emulator. The standardization of real computers would be a disaster - and so it probably won't happen.

38. Structured Programming supports the law of the excluded muddle.

39. Re graphics: A picture is worth 10K words - but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures.

40. There are two ways to write error-free programs; only the third one works.

41. Some programming languages manage to absorb change, but withstand progress.

42. You can measure a programmer's perspective by noting his attitude on the continuing vitality of FORTRAN.

43. In software systems it is often the early bird that makes the worm.

44. Sometimes I think the only universal in the computing field is the fetch-execute-cycle.

45. The goal of computation is the emulation of our synthetic abilities, not the understanding of our analytic ones.

46. Like punning, programming is a play on words.

47. As Will Rogers would have said, "There is no such thing as a free variable."

48. The best book on programming for the layman is "Alice in Wonderland"; but that's because it's the best book on anything for the layman.

49. Giving up on assembly language was the apple in our Garden of Eden: Languages whose use squanders machine cycles are sinful. The LISP machine now permits LISP programmers to abandon bra and fig-leaf.

50. When we understand knowledge-based systems, it will be as before - except our finger-tips will have been singed.

51. Bringing computers into the home won't change either one, but may revitalize the corner saloon.

52. Systems have sub-systems and sub-systems have sub-systems and so on ad infinitum - which is why we're always starting over.

53. So many good ideas are never heard from again once they embark in a voyage on the semantic gulf.

54. Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.

55. A LISP programmer knows the value of everything, but the cost of nothing.

56. Software is under a constant tension. Being symbolic it is arbitrarily perfectible; but also it is arbitrarily changeable.

57. It is easier to change the specification to fit the program than vice versa.

58. Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

59. In English every word can be verbed. Would that it were so in our programming languages.

60. Dana Scott is the Church of the Lattice-Way Saints.

61. In programming, as in everything else, to be in error is to be reborn.

62. In computing, invariants are ephemeral.

63. When we write programs that "learn", it turns out we do and they don't.

64. Often it is means that justify ends: Goals advance technique and technique survives even when goal structures crumble.

65. Make no mistake about it: Computers process numbers - not symbols. We measure our understanding (and control) by the extent to which we can arithmetize an activity.

66. Making something variable is easy. Controlling ration of constancy is the trick.

67. Think of all the psychic energy expended in seeking a fundamental distinction between "algorithm" and "program".

68. If we believe in data structures, we must believe in independent (hence simultaneous) processing. For why else would we collect items within a structure? Why do we tolerate languages that give us the one without the other?

69. In a 5 year period we get one superb programming language. Only we can't control when the 5 year period will begin.

70. Over the centuries the Indians developed sign language for communicating phenomena of interest. Programmers from different tribes (FORTRAN, LISP, ALGOL, SNOBOL, etc.) could use one that doesn't require them to carry a blackboard on their ponies.

71. Documentation is like term insurance: It satisfies because almost no one who subscribes to it depends on its benefits.

72. An adequate bootstrap is a contradiction in terms.

73. It is not a language's weaknesses but its strengths that control the gradient of its change: Alas, a language never escapes its embryonic sac.

74. It is possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as soap bubble?

75. Because of its vitality, the computing field is always in desperate need of new cliches: Banality soothes our nerves.

76. It is the user who should parameterize proceres, not their creators.

77. The cybernetic exchange between man, computer and algorithm is like a game of musical chairs: The frantic search for balance always leaves one of the three standing ill at ease.

㈨ 加工中心分層銑圓用宏程序怎麼編程

關於宏程序編程，步驟細致復雜，要對宏程序有相當的了解。

舉一個例題如下：

1、例如加工一個長半軸30，短半軸20一個橢圓，橢圓不是圓弧，所以我們不能用圓弧的方式來加橢圓，這里我們用一小段一小段的直線來拼接這個橢圓。

㈩ 為什麼說面向對象編程和函數式編程

先從結構化編程說起

很久以前，軟體開發的世界還是一片渾渾噩噩，不管開發什麼軟體都面臨著復雜性這個問題，代碼裡面到處是goto語句，程序的流程隨意跳轉。眾生寫代碼時，越寫到後面越不知道自己寫的是什麼。這時候出現一位巨人，它就是結構化編程。

結構化編程的基本思想是：

有序地控制流程，即把程序的執行順序限制為順序、分支和循環這三種；
把共通的處理歸結為常式（函數）。
結構化編程的好處是：

三大限制：大大降低了程序的自由度，減少了各種組合，使得程序不至於太過復雜。對於這一點，結構化編程的順序、分支和循環可以實現一切演算法，雖然降低了程序的復雜性和靈活性，但是程序的實現能力並沒有降低。
常式（函數）：我們只需要知道過程（函數）的名字，而不需要知道過程的內部細節，即「黑盒化」。
雖然結構化解決了程序控制流的復雜問題，但程序裡面不僅包括控制結構，還包括要處理的數據。隨著處理數據的增加，程序的復雜性也會上升。這時候，面向對象編程來了！

面向對象的由來

「分別管理程序處理內容和處理數據對象所帶來的復雜性」問題是，為了得到正確的結果，必須保持處理和數據的一致性，這在結構化編程中是非常困難的，解決這一問題的方案就是數據抽象技術。

數據抽象是數據和處理方法的結合。這便是最初「對象」一詞的得來。面向對象編程也因此得名。

然後，從抽象原則來說，多個相同事物出現時，應該組合在一起，即DRY原則(Don't Repeat Yourself)，便又引出了類這一概念。

根據數據類型來進行合適的處理（調用合適的方法），本來就應該是編程語言這種工具應該完成的事。這便是多態的引出了。

而對於繼承，大部分的觀點是「繼承是隨著程序的結構化和抽象化自然進化而來的一種方式」。結構化和抽象化，意味著把共通部分提取出來生成父類的自底向上的方法。（如果繼承是這樣誕生的話，那麼最初，有多個父類的多重繼承就會成為主流，而實際上最初引入繼承的Simula語言只提供單一繼承。松本行弘認為繼承的原本目的實際是逐步細化）