Lập trình OO có thực sự quan trọng như các công ty tuyển dụng đặt nó không? [đóng cửa]

Tôi chỉ hoàn thành bằng thạc sĩ (về điện toán) và xin việc. Tôi đã nhận thấy nhiều công ty đặc biệt yêu cầu sự hiểu biết về định hướng đối tượng. Các câu hỏi phỏng vấn phổ biến là về thừa kế, đa hình, phụ kiện, vv

OO có thực sự quan trọng? Tôi thậm chí đã có một cuộc phỏng vấn cho một công việc lập trình ở C và một nửa cuộc phỏng vấn là OO.

Trong thế giới thực, phát triển các ứng dụng thực, định hướng đối tượng gần như luôn được sử dụng? Là các tính năng chính như đa hình được sử dụng rất nhiều?

Tôi nghĩ rằng câu hỏi của tôi đến từ một trong những điểm yếu của tôi. Mặc dù tôi biết về OO, tôi dường như không thể kết hợp nó rất nhiều vào các chương trình của mình.

OOP là một mô hình cho phép chương trình của bạn phát triển mà không thể duy trì / hiểu được. Đây là một điểm mà sinh viên gần như không bao giờ có được bởi vì họ chỉ thực hiện các dự án nhỏ kéo dài từ hai tuần đến hai tháng nhiều nhất.

Khoảng thời gian ngắn này không đủ để làm rõ mục tiêu của OOP, đặc biệt nếu những người trong dự án là người mới bắt đầu. Nhưng việc tuân thủ một số sửa đổi là rất quan trọng đối với các dự án lớn, tôi sẽ nói> 50.000 dòng mã. OOP không phải là giải pháp duy nhất cho vấn đề đó, nhưng đây là giải pháp được sử dụng rộng rãi nhất trong ngành.

Đây là lý do tại sao mọi người muốn bạn biết OOP.

Tôi sẽ nói thêm rằng, gần như tất cả các lập trình viên cơ sở đều có lỗ hổng nghiêm trọng trong việc sửa đổi và OOP. Hầu hết trong số họ biết cách viết các lớp, kế thừa từ chúng và những thứ cơ bản như thế, nhưng họ không nghĩ trong "OOP" và cuối cùng lại lạm dụng nó. Đây là lý do tại sao bất kỳ nhà tuyển dụng nghiêm túc nào cũng sẽ luôn xem xét năng lực của bạn trong miền OOP.

Vì những điều này không được học ở trường, có một sự thay đổi lớn về kiến ​​thức giữa các ứng cử viên khác nhau. Và hãy thành thật nhất: Tôi không nghĩ ai đó có kiến ​​thức kém trong OOP có thể làm việc cho bất kỳ dự án lớn nào, đơn giản vì nó sẽ cần nhiều thời gian hơn cho các nhà phát triển chính để quản lý những người này hơn là chỉ đơn giản là tự viết mã.

Nếu bạn chưa nghĩ "OOP", tôi sẽ đề nghị bạn đọc một số cuốn sách về nó và áp dụng trong công ty không có các dự án thực sự lớn; để làm quen với OOP tiếp tục làm công việc hữu ích cho chủ nhân của bạn (và miễn là anh ấy / cô ấy đưa cho bạn mức lương của bạn, điều này cũng sẽ hữu ích cho bạn).

EDIT: ha, và tôi sẽ nói thêm rằng tôi đã viết mã OOP bằng C, ngay cả khi đó không phải là cách sử dụng C phổ biến nhất, điều này là có thể với kiến ​​thức mạnh mẽ. Bạn chỉ cần xây dựng vtables bằng tay.

Và đằng sau kỹ thuật OOP, một cái gì đó được ẩn giấu: thiết kế phần mềm. Thiết kế phần mềm, thực sự hữu ích, bằng C như trong bất kỳ ngôn ngữ nào khác. Nhiều nhà tuyển dụng sẽ kiểm tra năng lực thiết kế phần mềm của bạn và câu hỏi OOP rất tốt cho điều đó, nhưng OOP không phải là điều chính đang được thử nghiệm ở đây. Đây là lý do tại sao bạn có những câu hỏi đó ngay cả đối với công việc C.

Vấn đề áp đảo với lập trình máy tính là xử lý sự phức tạp và các chương trình hiện đại thực sự có thể rất phức tạp và điều này dường như chỉ tăng lên.

Phần lớn công việc được thực hiện trong công nghệ phần mềm của các chương trình máy tính không tầm thường tập trung vào việc thuần hóa sự phức tạp và làm cho nó có thể truy cập được càng nhiều càng tốt mà không dành cả đời để học trước.

Ví dụ:

• Modularization: Bạn làm cho các chương trình đơn giản hơn về mặt khái niệm bằng cách có các mô-đun mã, trong đó mỗi mô-đun chỉ biết một chút về các mô-đun khác (thay vì định tuyến biểu tượng chuột được phép thao tác trực tiếp bộ đệm thẻ mạng).
• API: Chúng đưa ra đường dẫn sử dụng đơn giản cho các chương trình phức tạp đằng sau API. Khi bạn mở tệp, bạn không quan tâm rằng chia sẻ mạng được xử lý khác với đĩa USB. API là như nhau.
• Hướng đối tượng. Điều này cho phép bạn sử dụng lại mã hiện có và làm cho nó hoạt động minh bạch với mã mới mà bạn thêm vào, trong khi vẫn ẩn tất cả sự phức tạp tiềm ẩn.

Nói cách khác, biết nhiều thủ thuật là cần thiết nếu bạn muốn làm việc trên các phần mềm không tầm thường, một mình hoặc (rất có thể) với người khác.

Đúng, chủ yếu bởi vì có lẽ hai nền tảng phát triển phổ biến nhất được sử dụng trong phát triển thương mại (Java và .NET) đều hướng đối tượng và điều đó có nghĩa là có, OO được sử dụng rất nhiều (bao gồm đa hình, kế thừa và mọi thứ khác).

Các công ty không đặc biệt quan tâm đến định hướng đối tượng như một công nghệ - đây không phải là một ý thức hệ, họ quan tâm đến những người có thể phát triển giải pháp cho các vấn đề của họ theo cách phù hợp với chiến lược CNTT của họ.

Nhưng tôi sẽ không lo lắng quá nhiều về việc cảm thấy đó là một điểm yếu. Không tôn trọng giáo dục của bạn, hầu hết mọi người trong thế giới thương mại không xem các lập trình viên rời trường đại học (ở bất kỳ cấp độ nào) là bài báo đã hoàn thành. Bạn vẫn còn rất nhiều điều để học và điều đó được hiểu (có lẽ bởi các công ty tốt hơn so với các sinh viên).

Như trong cuộc sống thực, lập trình thực tế khác với lý thuyết.

Có, nếu bạn giữ mô hình OO được đánh bóng và luôn ở phía sau tâm trí của bạn, bạn có thể làm tốt hơn trong việc viết mã có thể quản lý, dễ hiểu và dễ dàng mở rộng.

Thật không may, thế giới thực có điều này:

• áp lực thời gian dự án
• thành viên nhóm định hướng thủ tục
• đội chéo, nhiều nhà cung cấp
• mã kế thừa không có bất kỳ định hướng nào
• miễn là nó hoạt động, một vài quan tâm về cách viết mã
• ngay cả khi mã không hoạt động, động lực là để sửa nó, chứ không phải "OO" nó
• mô-đun, giới hạn nền tảng, khung mà đơn giản là không cho phép bạn thực hiện OO tốt

Trong một công việc thực tế, bạn phải làm việc với các vấn đề trên. Điều này nghe có vẻ mất tinh thần. Nhưng, coi điều này như một cái đầu lên. Các công ty tuyển dụng đặt quá nhiều tầm quan trọng vào OO trong khi tuyển dụng. Thật dễ dàng để biết lý do tại sao. Cách duy nhất họ có thể kiểm tra ứng viên là hỏi về sự hiểu biết về OO. Và thật không may, nhiều ứng viên chỉ kiểm tra những câu hỏi đó trước khi đến phỏng vấn.

OO ngoài đời thực đến chậm. Nó giúp nếu bạn tiếp tục đọc và tiếp tục cải thiện nó theo thời gian.

Tôi hoàn toàn có cùng cảm giác khi hoàn thành bằng Cử nhân của mình, và một cuốn sách tuyệt vời cho tôi thấy lý do tại sao và làm thế nào OOP có liên quan đến các ứng dụng trong thế giới thực là Head First: Design Forms . Tôi chân thành khuyên bạn nên xem qua, nó được viết theo một cách thực sự thú vị và đưa ra nhiều điểm hợp lệ về lý do tại sao phương pháp OOP được mong muốn khi làm việc với các hệ thống quy mô lớn hơn, liên tục thay đổi.

Ngay cả đối với một số công việc trong C, bạn có thể cần biết thiết kế hướng đối tượng (và có thể tốt hơn so với trình biên dịch của bạn đã làm cho bạn), bằng chứng là một loạt bài viết gần đây về thiết kế hướng đối tượng trong nhân Linux. ( Phần 1 , Phần 2 )

GTK + cũng sử dụng rất nhiều mẫu thiết kế hướng đối tượng.

Tôi phải bày tỏ một số bất đồng với khái niệm này rằng OO là tất cả - người ta có thể nói OO cho phép bạn xây dựng các thành phố, nhưng các chương trình thủ tục là những viên gạch.

Để đưa ra câu trả lời của tôi dưới dạng tương tự, một đối tượng cần chung, người lính cần thủ tục. Khi bạn đi sâu vào OO, bạn sẽ tìm thấy các quy trình và nếu đó là chuyên môn của bạn và bạn đủ tốt, đừng lo lắng về OO, vì ai đó đủ dễ dàng để viết mã trò chơi cờ vua OO này:

-findBestMove
-makeBestMove
-waitForPlayerInput

nhưng sau đó ai đó phải viết mã phía sau -findBestMove và bạn có thể chắc chắn rằng đó không phải là điều này:

foreach $move (@moves){
    $bestMove = ($move > $bestMove ? $move : $bestMove)
}
return $bestMove

Mặt khác, nếu bạn không biết cách đọc mã OO, hãy lo lắng. Bởi vì bạn có thể chắc chắn (gần như) rằng mã của bạn sẽ bị rối với các đối tượng thuộc loại nào đó. Trừ khi bạn làm việc trên mạng lưới di sản fortran của 12000 vars toàn cầu và 1200 "mô-đun" dòng tôi hiện đang duy trì.

Jon Hopkins đã viết:

Đúng, chủ yếu bởi vì có lẽ hai nền tảng phát triển phổ biến nhất được sử dụng trong phát triển thương mại (Java và .NET) đều hướng đối tượng và điều đó có nghĩa là có, OO được sử dụng rất nhiều (bao gồm đa hình, kế thừa và mọi thứ khác).

Đó là khá nhiều những gì tôi sẽ nói, nhưng không chỉ có Java và .Net, C ++ có ở khắp mọi nơi, Objective-C có trên OSX, tất cả những đứa trẻ tuyệt vời đang làm Ruby hoặc Python, và tất cả những thứ này và nhiều thứ khác nhiều hơn có một tập trung vào định hướng đối tượng. Rất nhiều ngôn ngữ mới hơn là đa ngôn ngữ, do đó, một số ngôn ngữ như F # chủ yếu là ngôn ngữ chức năng, nhưng cũng hỗ trợ định hướng đối tượng. Nó ở khắp mọi nơi, và có ít nhất một số hiểu biết là rất hữu ích. Đừng băn khoăn quá nhiều về nó, mặc dù vừa hoàn thành các khóa học đại học có nghĩa là bạn đã sẵn sàng để bắt đầu học về phát triển mã trong thế giới thực :)

Tôi đã thực hiện lập trình trong một thời gian dài và tôi thấy các khái niệm về OO rất hữu ích ngay cả khi lập trình bằng C - mặc dù nếu được kiểm tra tôi có thể sẽ không mô tả các khái niệm đó trong từng chi tiết nhỏ. Tại một thời điểm, tôi thậm chí đã tạo ra một ngôn ngữ OO, mặc dù là ngôn ngữ thô sơ, để tìm hiểu về các khái niệm và tìm kiếm sự thích thú trong OO từ một góc độ mới.

BTW, C ++ đã tạo ra một mớ hỗn độn khổng lồ và xấu xí của OO, trong khi Objective C làm đúng.

Về các cuộc phỏng vấn, họ đã trở thành một chương trình kinh dị - từ cả hai phía của bàn. Hầu hết những người được phỏng vấn đều rất bối rối bởi họ. Hầu hết các nhà quản lý tuyển dụng đều ngạc nhiên bởi có nhiều người thất bại ngay cả các bài kiểm tra lập trình rất cơ bản.

Điều đó nói rằng, có một số túi thụt rửa khổng lồ làm việc trong ngành công nghiệp phần mềm ngay bây giờ, những người không biết gì và vẫn mong đợi thế giới từ các nhân viên tương lai.

Học OOP không hữu ích như học phát triển phần mềm. Đi đọc Mã hoàn thành 2 .

Chắc chắn đó là một công cụ hữu ích nhưng bản thân OOP thực sự rất nhỏ. Nói chung khi các công ty và nhà tuyển dụng nói "OOP", họ có nghĩa là "Phát triển phần mềm". Nó đang được sử dụng như một thuật ngữ chung.

Các nhà tuyển dụng thực sự sẽ cho biết sự khác biệt giữa bạn biết cách phát triển phần mềm và khớp với hộp thư "Đã 3 năm trong 'OOP'".

Câu trả lời là có, như một số người khác đã lưu ý.

NHƯNG, nếu bạn muốn làm việc với hàng đống mã spaghetti không theo thủ tục OO, bạn cũng có thể tìm thấy điều đó. Tôi nghĩ bạn sẽ thích công việc OO.

EDIT: Hãy tha thứ cho trường hợp của tôi về sự hoài nghi và sự hài hước của xạ thủ. Như Raynos đã nói, chỉ vì một cái gì đó là OO không có nghĩa là nó tốt. Áp dụng đúng OO cần có công việc và suy nghĩ thực tế; chỉ có các phiên bản của nó không tự động có nghĩa là một ứng dụng được thực hiện tốt. Và ngược lại, tôi chắc chắn có mã thủ tục bằng văn bản ngoài đó. Kinh nghiệm của tôi trong các cửa hàng CNTT của công ty trong suốt thập niên 90 và 2000 là rất nhiều mã xấu đã được viết và có lẽ vẫn còn tồn tại. Nhưng gần hơn với câu hỏi của OP, tôi đã nhận thấy rằng các nhà phát triển thông minh hơn, khi có cơ hội, sẽ chuyển sang nhiều hệ thống OO hơn.

OO là một cơ sở cơ bản mà trên đó các kỹ thuật khác được xây dựng. Một điểm quan trọng trước tiên là phải hiểu đầy đủ sự khác biệt giữa một loại (lớp) và một thể hiện của loại đó. Đừng cố đọc tiếp mà không hiểu đầy đủ về điều đó (nghĩ rằng nó sẽ trở nên rõ ràng hơn sau này), bởi vì bạn sẽ phải đọc lại phần còn lại một lần nữa khi bạn bắt gặp tầm nhìn.

Một khi bạn đã hiểu rõ về nó, bạn sẽ không bao giờ muốn làm gì nếu không có nó. Tôi không phải là người theo chủ nghĩa thuần túy khi nói đến việc đóng gói, mô hình, khung hoặc bất cứ điều gì. Trong công việc, bạn sẽ phải thích nghi với nhiều quan điểm và khái niệm khác nhau. Tôi sẽ liệt kê một số kinh nghiệm làm việc trước đây của riêng tôi:

Tại một công ty, các đồng nghiệp của tôi muốn tải càng nhiều càng tốt (các nhà xây dựng trống, các thuộc tính cồng kềnh phải kiểm tra giá trị null ở mọi nơi). Họ đang xây dựng các đối tượng phía máy chủ dựa trên web sống một cuộc đời ngắn ngủi.

Công việc tiếp theo hoàn toàn ngược lại. Các đối tượng sống trong một ứng dụng máy tính để bàn (dựa trên Excel). Càng nhiều khởi tạo càng tốt trong hàm tạo (hoặc một trong nhiều quá tải của hàm tạo). Các nhà xây dựng trống không được phép vì các đối tượng trống không có quyền tồn tại (điều này khiến cho việc kiên trì trở thành một thách thức). Ngoài ra, tôi phải thích ứng với "tiêu chuẩn kiểu mã hóa" của họ (nơi mở dấu ngoặc đơn, thêm khoảng trắng sau khi nhận xét, v.v.), bởi vì mã của tôi không thể được kiểm tra nếu nó không thông qua cop-style.

Hiện tại tôi đang làm việc tại một công ty nơi không có nhà phát triển nào từng cố gắng hiểu OO. Thật khó để diễn tả mức độ cực kỳ bực bội của nó. Tôi đã phải cải thiện các kỹ năng Grep của mình, trên thực tế tôi có macro HotScripts được gán cho khóa F12 của mình để thực hiện một grep trên văn bản đã chọn. Tôi sẽ giải phóng những nỗi thất vọng khác ...

Khi bạn có được kỹ năng OO, bạn sẽ gần như bị dị ứng với spaghetti! Tuy nhiên, trong mọi trường hợp, OO - hoặc không, hãy kiên nhẫn và thích nghi. Hãy miễn cưỡng "vứt nó đi và bắt đầu lại". Sếp của bạn sẽ chọn bạn khi nói đến việc vứt bỏ. Thật không may "làm cho mony" quan trọng hơn mã thanh lịch.

Xin lỗi vì câu trả lời dài nhưng tôi đã cố gắng bao quát hầu hết phạm vi câu hỏi của bạn :-)

OOP không quan trọng vì bản thân nó, nhưng vì những gì nó mang theo. Một cái gì đó liên quan đến khả năng trừu tượng hóa và cô lập, những thứ nhóm lại kết thúc chỉ phơi bày những phần được yêu cầu để tương tác với nhau.

Đây là một kỹ thuật kỹ thuật phổ biến được gọi là "mô đun hóa", cho phép tạo ra các hệ thống phức tạp dưới dạng tổng hợp của các hệ thống đơn giản hơn, không cần quan tâm đến từng chi tiết ở mức cao và yêu cầu các thành phần phải có thể thay thế được, ngay cả khi không có chúng chính xác tương tự.

Những "khái niệm kỹ thuật" đó đã được cố gắng duy trì để phát triển phần mềm từ khi chính sản phẩm phần mềm trở nên lớn hơn "khả năng của nhà phát triển duy nhất", do đó đòi hỏi một cách để khiến các nhà phát triển làm việc trên các phần độc lập và để những phần đó làm tương tác với nhau.

Điều đó nói rằng, những nguyên tắc đó không nhất thiết chỉ được tìm thấy trong OOP (lý thuyết tính toán là hợp lệ, có những phương pháp khả thi vô hạn để đi đến những kết quả đó).

OOP chỉ đơn giản là một nỗ lực thành công để kết hợp những điều đó lại với nhau, đưa ra những thuật ngữ chung đó (như mô-đun, đóng gói, thay thế) các định nghĩa chính xác hơn và khái niệm hóa công phu trên các định nghĩa (mẫu) có thể phù hợp với ngôn ngữ lập trình.

Trước tiên, hãy nghĩ đến OOP không phải là một " tính năng ngôn ngữ " mà là một " từ vựng thông thường " khiến các kỹ sư phần mềm tiếp cận với thiết kế phần mềm.

Thực tế là một ngôn ngữ nhất định có hoặc không nguyên thủy trực tiếp thực thi từ vựng đó đảm bảo - ví dụ - rằng "viên nang" không được mở ra một cách vô tình bởi ai không được phép làm đó là khía cạnh thứ yếu của thiết kế OOP. Đó là lý do tại sao ngay cả dự án C lớn thường được "quản lý" OOP, ngay cả khi chính ngôn ngữ đó không hỗ trợ trực tiếp cho điều đó.

Lợi thế của tất cả những gì không thể nhận ra cho đến khi quy mô dự án nằm trong khả năng của nhà phát triển duy nhất trong việc hiểu và theo dõi mọi thứ anh ta làm (thực tế, trong tình huống đó, nó thậm chí có thể được xem là "trên cao") hoặc vào một nhóm nhỏ phát triển một cái gì đó trong một khoảng thời gian ngắn. Và đó là lý do chính khiến những người đàn em nghiên cứu OOP về "tính năng ngôn ngữ" thường hiểu sai rằng nó tạo ra mã được thiết kế xấu.

Cách OOP phù hợp với các ngôn ngữ phụ thuộc vào cách các nhà thiết kế ngôn ngữ diễn giải nguyên tắc OOP trong cấu trúc của chính họ.

Vì vậy, "đóng gói" trong C ++ trở thành "thành viên riêng" (và "viên nang" trở thành một lớp), "thay thế" trở thành chức năng ảo ghi đè hoặc tham số mẫu / chuyên môn hóa, v.v., trong khi trong D, một viên nang là một "mô-đun" (và thay thế đi thông qua các lớp, v.v.), do đó làm cho mô hình hoặc mẫu nhất định có sẵn trực tiếp trong một ngôn ngữ nhất định và không phải trong một ngôn ngữ khác và vv.

Những gì nhà tuyển dụng tìm kiếm khi đặt câu hỏi OOP chỉ là kiểm tra khả năng của bạn để trừu tượng hóa và che giấu thiết kế phần mềm cho các dự án lớn và phát triển trong tương lai. OOP, đối với họ chỉ là một "từ điển" mà họ cho rằng cả bạn và họ đều biết để bạn có thể nói về những điều chung chung khác hoặc cụ thể hóa thành một triển khai cụ thể.

Một ngôn ngữ hướng đối tượng giúp bạn giữ một thiết kế hướng đối tượng trong mã của bạn, điều này là tốt. Nhưng cũng đúng là một thiết kế như vậy có thể đạt được với bất kỳ ngôn ngữ mô hình nào khác: lý do phổ biến (đặc biệt là giữa các công ty) của ngôn ngữ OO có lẽ là thành công thương mại của java và c #.

Nếu ông Gates bắt đầu công ty của mình đúng cách, có lẽ chúng tôi sẽ học SCHEME trước khi xin việc.

Câu trả lời ngắn gọn là Có

Phiên bản dài hơn tại sao bạn cảm thấy hoặc trong tình huống khó xử về lý do tại sao nó quan trọng chỉ là do bạn chưa từng làm việc với bất kỳ dự án hoặc triển khai nào phục vụ mục đích nào đó. Nó hoàn toàn hợp lệ trong các lớp học để có các ví dụ về Ô tô sau đó mở rộng sang Ô tô, Xe tải ... nhưng khi bạn bắt đầu phát triển phần mềm, đó là một giải pháp được nhắm mục tiêu để dễ dàng thực hiện một số nhiệm vụ. Bây giờ nếu không phải là OOchúng ta sẽ có mọi người viết mã tương tự trên cơ sở mã hoặcphát minh lại bánh xe hàng ngày. Hãy tưởng tượng nó sẽ là một mớ hỗn độn như thế nào nếu một người lao vào một cơ sở mã như vậy để sửa chữa một cái gì đó. Các ví dụ trong lớp học là một định nghĩa mơ hồ hoặc đại diện về cách thức / lý do tại sao nó được thực hiện. Thử nghiệm thực sự đã được đưa ra khi bạn bắt đầu xây dựng ứng dụng của mình, không còn nghi ngờ gì nữa vì nó có thể được sử dụng khủng khiếp nhưng nó vượt xa sự cân bằng do cách sử dụng rõ ràng và súc tích. Vì vậy, tốt hơn là bắt đầu làm việc trên các khu vực yếu này, ít nhất là bạn tạo ra các mã ác mộng.

Nó phụ thuộc. Một lý do bạn cần biết OO vì đó là ngôn ngữ chung của thế giới lập trình. Như một câu trả lời khác chỉ ra, gần như mọi ngôn ngữ chính là OO theo một cách nào đó, điều đó có nghĩa là về cơ bản, bất kỳ công ty nào có thể thuê bạn đều sử dụng ngôn ngữ OO. Bao giờ thử tuyển lập trình viên OCaml? Điều đó là không thể; quỹ tài năng quá nhỏ. Nếu bạn bắt đầu công ty của mình bằng OCaml và công ty của bạn thành công, bạn sẽ không thể thuê lập trình viên đủ nhanh và bạn sẽ rời bỏ công việc. Do đó, gần như mọi công ty có hơn 3 lập trình viên đều sử dụng ngôn ngữ OO và để giao tiếp với đồng nghiệp và sử dụng thư viện nền tảng của bạn, bạn sẽ cần phải hiểu về OO.

Tùy thuộc vào ngôn ngữ cụ thể mà công ty đang sử dụng, tính kế thừa và tính đa hình là cực kỳ quan trọng hoặc chỉ liên quan ở mức độ vừa phải. Bạn không thể làm bất cứ điều gì trong Java mà không cần rút ra 10 mẫu thiết kế GoF và khung tiêm phụ thuộc. Java là một trong những ngôn ngữ được sử dụng rộng rãi nhất, do đó các nguyên tắc OO thực sự quan trọng đối với nhiều công ty sử dụng Java.

Nếu công ty đang sử dụng ngôn ngữ OO / chức năng lai hiện đại có lambdas và con trỏ hàm, như Scala hoặc C #, thì việc thừa kế đột nhiên trở nên ít quan trọng hơn vì bạn có các hàm bậc cao hơn để xử lý nhiều điều thực sự đơn giản mà nếu không yêu cầu nhiều Lễ. Tuy nhiên, bạn vẫn cần có khả năng làm việc với các công cụ OO vì hầu hết các thư viện bạn sử dụng sẽ được viết theo cách OO.

Nếu tính kế thừa và đa hình không quan trọng đối với công ty, bạn vẫn có thể nhận được câu hỏi OO vì:

• Bạn được phỏng vấn bởi một người nhân sự không biết gì về lập trình và đang đặt câu hỏi ra khỏi danh sách kiểm tra. Bạn có 3 năm X, bạn có đa nhiệm không, v.v.
• Bạn được phỏng vấn bởi một kỹ sư muốn chắc chắn rằng bạn chưa từng sống dưới một tảng đá. OO là ngôn ngữ chung, vì vậy bạn sẽ được hỏi một số câu hỏi khó hiểu về nó.
• Bạn được phỏng vấn bởi một kỹ sư không giỏi về phỏng vấn. Nói chung, các kỹ sư thích những thứ lặt vặt và phức tạp, vì vậy bạn sẽ nhận được rất nhiều câu hỏi về đa hình, kế thừa và các mẫu thiết kế GoF chỉ vì những điều này rất thú vị với người phỏng vấn bạn.

Trong một từ "Có".

Bạn có thể nghĩ rằng bạn biết lý thuyết, nhưng bạn cần viết một số mã và đưa nó vào thực tế. Có - theo nghĩa đen - hàng ngàn ví dụ và bài tập có sẵn trên mạng.