Làm thế nào tôi có thể thực hành lập trình hướng đối tượng tốt hơn? [đóng cửa]

Tôi đã lập trình bằng ngôn ngữ hướng đối tượng trong nhiều năm nay nhưng tôi thầm ghen tị khi nhìn vào một số công việc mà các đồng nghiệp của tôi làm. Rất nhiều người trong số họ dường như có một số bản năng OO bên trong mà tôi không có - bất kể tôi cố gắng thế nào. Tôi đã đọc tất cả những cuốn sách hay trên OO nhưng dường như vẫn không thể bẻ khóa được. Tôi cảm thấy mình giống như một người đã cống hiến 110% để trở thành một cầu thủ bóng đá chuyên nghiệp nhưng chỉ là không có tài năng thiên bẩm để làm nên điều đó. Tôi đang thất vọng và nghĩ đến việc chuyển đổi nghề nghiệp - tôi nên làm gì?

Tôi muốn nói rằng tập trung ít hơn vào lập trình OO và tập trung nhiều hơn vào thiết kế OO . Lấy một tờ giấy và một cây bút chì (hoặc có thể là một công cụ tạo mô hình UML) và rời khỏi màn hình.

Bằng cách thực hành cách thiết kế một hệ thống, bạn sẽ bắt đầu có được cảm giác tự nhiên về các mối quan hệ đối tượng. Mã chỉ là sản phẩm phụ của thiết kế. Vẽ sơ đồ và lập mô hình ứng dụng của bạn ở dạng hoàn toàn không phải mã. Các mối quan hệ là gì? Làm thế nào để các mô hình của bạn tương tác? Thậm chí không nghĩ về mã.

Khi bạn đã dành thời gian thiết kế ... thì hãy dịch nó sang mã. Bạn sẽ ngạc nhiên về tốc độ mã có thể được viết từ một thiết kế OO tốt.

Sau nhiều lần thực hành thiết kế, bạn sẽ bắt đầu thấy những khu vực chung có thể được mô-đun hóa hoặc trừu tượng hóa, và bạn sẽ thấy sự cải thiện trong cả thiết kế và mã của mình.

Cách dễ nhất là học các khái niệm như SOLID, DRY, FIT, DDD, TDD, MVC, v.v. Khi bạn tra cứu các từ viết tắt này, nó sẽ dẫn bạn xuống nhiều lỗ hổng khác và khi bạn đã đọc xong, bạn sẽ có hiểu rõ về lập trình hướng đối tượng tốt hơn là gì!

Podcast SOLID: http://www.hanselminutes.com/default.aspx?showID=168 , http://www.hanselminutes.com/default.aspx?showID=163

Sự cố SOLID: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

KHÔ: http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

PHÙ HỢP: http://www.netwellness.org/question.cfm/38221.htm

DDD: http://dddcommunity.org/

DDD yêu cầu đọc: http://www.infoq.com/minibooks/domain-driven-design-quickly

TDD: http://en.wikipedia.org/wiki/Test-driven_development

MVC: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Và vâng, xắn tay áo lên và viết mã luôn là một ý kiến ​​hay. Hãy thực hiện một dự án nhỏ với khả năng hiện tại của bạn. Sau đó, đọc một bài báo từ trên cao. Sau đó, cấu trúc lại mã của bạn để đáp ứng nhu cầu của những gì bạn vừa đọc. Lặp lại cho đến khi bạn đã cấu trúc lại mã của mình. Cuối cùng, bạn không chỉ biết OO là gì mà còn có thể giải thích tại sao nó quan trọng và làm thế nào để có được lần đầu tiên của họ. Học cách tái cấu trúc cũng là một chìa khóa để có mã tốt. Những gì ngay bây giờ không phải là ngày mai.

Quá nhiều người nghĩ đến việc viết mã đầu tiên, đối tượng, cuối cùng.

Bạn có thể đọc tất cả những cuốn sách bạn muốn nhưng điều đó sẽ không dạy bạn cách suy nghĩ theo hướng đối tượng - mà cần phải thực hành và một phương pháp luận nhất định.

1. Dưới đây là một vài phương pháp đã giúp ích cho tôi: Khi bạn không làm việc và cởi mở, bạn có thể thực hành bằng cách xem mọi thứ như một đối tượng . Đừng nhìn vào những đối tượng này và tự hỏi bạn sẽ lập trình chúng như thế nào, hãy xem chúng chỉ là thuộc tính và chức năng và cách chúng liên quan hoặc kế thừa từ nhau. Ví dụ, khi bạn nhìn thấy một người, họ là một đối tượng và do đó sẽ đại diện cho một lớp. Chúng có các đặc tính như màu tóc, màu da, chiều cao, v.v. Chúng cũng thực hiện một số chức năng nhất định. Họ đi bộ, nói chuyện, ngủ, v.v. Một số chức năng mà những người này thực hiện trả về kết quả. Ví dụ, hàm làm việc của chúng trả về một lượng đô la. Bạn có thể làm điều này với mọi thứ bạn thấy vì mọi thứ đều là một đối tượng. Xe đạp, ô tô, ngôi sao, v.v.

2. Trước khi viết mã một dự án, hãy thiết kế nó bằng cách sử dụng các ghi chú sau nó và một bảng xóa khô. Điều này sẽ thực hiện tốt cho đến khi bạn hiểu được điều này. Hãy nghĩ về đối tượng / chức năng / thuộc tính cụ thể của bạn. Mỗi mục đó sẽ có ghi chú riêng. Đặt chúng như một hệ thống phân cấp trên bảng xóa khô. Về vấn đề này, hàm / thuộc tính sẽ được đặt dưới đối tượng. Nếu bạn có một đối tượng khác, hãy làm tương tự cho đối tượng đó. Sau đó, hãy tự hỏi bản thân, làm bất kỳ bài đăng nào trong số này nó ghi chú (đối tượng / chức năng / thuộc tính) liên quan đến nhau. Nếu hai đối tượng sử dụng cùng một chức năng, hãy tạo một đối tượng mẹ (ghi chú post-it) và đặt nó lên trên những đối tượng khác với chức năng có thể sử dụng lại dưới ghi chú mới. Vẽ một đường bằng cách sử dụng bút đánh dấu xóa khô từ hai đối tượng con đến đối tượng chính.

3. Khi tất cả điều này được thực hiện, sau đó hãy lo lắng về nội bộ của cách hoạt động của lớp.

Đề nghị của tôi là học một cái gì đó khác biệt.

Học lập trình chức năng và áp dụng những gì bạn học được từ đó vào OOP. Nếu bạn biết C ++, hãy thử lập trình chung chung.

Học ngôn ngữ không hướng đối tượng.

Không chỉ vì bạn nên sử dụng tất cả những thứ này (bạn nên), hay vì chúng nên thay thế hoàn toàn OOP ( có thể không nên), mà bởi vì bạn cũng có thể áp dụng các bài học từ những thứ này cho OOP.

Bí mật của OOP là không phải lúc nào bạn cũng có thể sử dụng nó . Không phải mọi thứ đều là một đẳng cấp. Không phải mọi mối quan hệ hoặc phần hành vi đều nên được mô hình hóa như một lớp.

Cố gắng áp dụng OOP một cách mù quáng hoặc cố gắng viết mã OOP tốt nhất có thể có xu hướng dẫn đến những mớ hỗn độn được khai thác quá mức với quá nhiều mức độ trừu tượng và chuyển hướng và rất ít tính linh hoạt.

Đừng cố gắng viết mã OOP tốt. Cố gắng viết mã tốt. Và sử dụng OOP khi nó đóng góp vào mục tiêu đó.

Trong nhiều lĩnh vực, có một khoảnh khắc "eureka" nơi mọi thứ kết hợp với nhau.

Tôi nhớ mình đã cảm thấy thất vọng trong môn hình học ở trường trung học. Tôi không biết phải áp dụng định lý nào cho mỗi bước chứng minh. Nhưng tôi vẫn giữ nó. Tôi đã học chi tiết từng định lý và nghiên cứu cách chúng được áp dụng trong các chứng minh ví dụ khác nhau. Vì tôi không chỉ hiểu định nghĩa của mỗi định lý mà còn cách sử dụng nó, tôi đã xây dựng một "hộp công cụ" gồm các kỹ thuật quen thuộc mà tôi có thể rút ra khi cần thiết.

Tôi nghĩ nó cũng vậy trong lập trình. Đó là lý do tại sao các thuật toán, cấu trúc dữ liệu và các mẫu thiết kế được nghiên cứu và phân tích. Đọc một cuốn sách và hiểu được định nghĩa trừu tượng của một kỹ thuật là chưa đủ. Bạn cũng phải xem nó trong hành động.

Vì vậy, hãy thử đọc nhiều mã hơn , ngoài việc tự luyện viết nó. Đó là một vẻ đẹp của mã nguồn mở, bạn có thể tải xuống rất nhiều mã để nghiên cứu. Không phải tất cả mã đó đều tốt, nhưng việc nghiên cứu mã xấu có thể mang lại hiệu quả giáo dục giống như học mã tốt.

Học một ngôn ngữ khác! Hầu hết các nhà phát triển chỉ sử dụng Java (chỉ là một ví dụ) chỉ có hiểu biết hạn chế về OO vì họ không thể tách biệt các khái niệm và tính năng ngôn ngữ. Nếu bạn chưa biết nó, hãy xem python. Nếu bạn biết python, hãy học Ruby. Hoặc chọn một trong các ngôn ngữ chức năng.

Aswer là câu hỏi của bạn;)

Thực hành thực hành thực hành.

Xem lại mã của riêng bạn và học hỏi từ những sai lầm.

TDD đã giúp tôi rất nhiều trong việc cải thiện kỹ năng tổng thể của tôi bao gồm cả OOP.

Bạn càng viết nhiều mã, bạn sẽ càng nhận thấy nhiều cạm bẫy của các phương pháp lập trình nhất định. Sau khi đủ thời gian và đủ mã, bạn sẽ có thể xác định các dấu hiệu cảnh báo của những cạm bẫy này và có thể tránh chúng. Đôi khi khi tôi viết mã, tôi sẽ cảm thấy ngứa ngáy trong tâm trí và nói với tôi rằng có thể có cách tốt hơn để làm điều này, mặc dù nó làm những gì tôi cần. Một trong những điểm yếu lập trình lớn nhất của tôi là "phân tích quá mức" mọi thứ đến mức nó bắt đầu làm chậm đáng kể thời gian phát triển. Tôi đang cố gắng ngăn chặn những "cơn ngứa" này bằng cách dành nhiều thời gian hơn cho thiết kế, điều này thường dẫn đến việc viết mã ít hơn nhiều.

... bí mật, tôi nhìn vào một số việc đồng nghiệp của tôi làm với sự ghen tị. Rất nhiều người trong số họ dường như có một số bản năng OO bên trong mà tôi không có - bất kể tôi cố gắng thế nào ...

Tôi nghĩ rằng bạn đã trả lời câu hỏi của riêng bạn ở đây. Đọc mã tốt là một khởi đầu tốt, và hiểu mã tốt thậm chí còn tốt hơn, nhưng hiểu các bước để có được mã tốt đó là tốt nhất. Khi bạn thấy một số mã mà bạn ghen tị, có lẽ bạn có thể hỏi tác giả làm thế nào anh ấy / cô ấy đạt được giải pháp đó. Điều này hoàn toàn phụ thuộc vào môi trường làm việc cũng như các mối quan hệ với đồng nghiệp của bạn. Trong bất kỳ trường hợp nào, nếu có ai hỏi tôi quá trình suy nghĩ đằng sau bất kỳ đoạn mã nào tôi viết, tôi không ngần ngại nói với họ vì tôi biết tôi cũng muốn họ làm điều tương tự cho tôi.

Các nhà thiết kế ngôn ngữ đã giải thích "Lập trình hướng đối tượng" theo nhiều cách khác nhau. Ví dụ: hãy xem Alan Kay, người đầu tiên sử dụng thuật ngữ OOP, đã định nghĩa nó như thế nào:

Đối với tôi, OOP chỉ có nghĩa là nhắn tin, lưu giữ cục bộ và bảo vệ, đồng thời ẩn quy trình trạng thái và ràng buộc quá muộn của tất cả mọi thứ. Nó có thể được thực hiện trong Smalltalk và trong LISP. Có thể có những hệ thống khác mà điều này có thể thực hiện được, nhưng tôi không biết về chúng.

(Trích dẫn từ http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en ).

Có vẻ lạ khi anh ấy không coi các ngôn ngữ OOP Java và C ++! Nhưng với tư cách là người thiết kế một trong những ngôn ngữ OOP đầu tiên và tốt nhất (Smalltalk), anh ấy có lý do chính đáng của riêng mình cho điều đó. Tại sao Alan Kay lại coi Lisp là một ngôn ngữ Hướng đối tượng mà không phải là Java? Câu hỏi đó đòi hỏi sự xem xét nghiêm túc của bất kỳ ai tuyên bố hiểu OOP.

Erlang có một cách phát triển OOP hoàn toàn khác , Scheme có một cách khác. Đó là giá trị xem xét tất cả các quan điểm thay thế này. Nếu có thể học tất cả các ngôn ngữ này! Điều đó sẽ mang lại cho bạn một cái nhìn rộng hơn, đưa vào tay bạn một số công cụ mới và mạnh mẽ và biến bạn trở thành một lập trình viên giỏi hơn.

Tôi đã tóm tắt các thử nghiệm của mình với việc triển khai ngôn ngữ OOP, dựa trên các ý tưởng vay mượn từ Smalltalk, Scheme và Erlang trong bài viết này .

       public void MasteryOfOOP() 
    { 
       while(true)

        /* My suggestion is: */
     DO: find a lot of well-written object oriented code and read it.  Then 
try to use the insights from it on your own coding.  Then do it again.  Then 
have a colleague who is a good OOP look at it and comment. Maybe post a chunk 
of your code on SO and ask for how it could be improved.

        Then read some more of those books.  Maybe they make a little more 
sense now...?

        Now go back to the top of this post, and do it again. 

        Repeat Forever.

        }
    }

Nếu bạn không biết cách thiết kế hệ thống hướng đối tượng, hãy bắt đầu với dữ liệu. Tìm ra những thứ bạn cần theo dõi và những thông tin nào kết hợp với nhau một cách tự nhiên (ví dụ: tất cả các thông số kỹ thuật của một nhóm xe hơi với nhau một cách độc đáo).

Mỗi loại trong số những thứ bạn quyết định theo dõi sẽ trở thành một lớp.

Sau đó, khi bạn cần có thể thực hiện các hành động cụ thể (ví dụ: đánh dấu một mẫu ô tô là ngừng hoạt động) hoặc đặt các câu hỏi cụ thể (ví dụ: hỏi số lượng một mẫu ô tô nhất định đã được bán trong một năm nhất định), bạn tải chức năng đó vào lớp mà nó tương tác nhiều nhất.

Nói chung, luôn phải có một nơi khá tự nhiên để một đoạn mã nhất định tồn tại trong cấu trúc lớp của bạn. Nếu không có, điều đó báo hiệu rằng có một nơi mà cấu trúc cần được xây dựng.

Có quá nhiều thông tin về các đối tượng. Điều quan trọng nhất là phải nắm vững những điều cơ bản và mọi thứ sẽ rơi vào vị trí dễ dàng hơn.

Đây là một cách để suy nghĩ về các đối tượng. Suy nghĩ về cấu trúc dữ liệu trong các ngôn ngữ thủ tục. Chúng là một nhóm các trường không có hành vi. Hãy nghĩ về các hàm nhận con trỏ đến các cấu trúc dữ liệu đó và thao tác với cấu trúc sau. Bây giờ, thay vì để chúng tách biệt, hãy xác định các chức năng bên trong định nghĩa của cấu trúc và giả sử các hàm thường nhận một con trỏ đến cấu trúc dữ liệu để thao tác. Con trỏ đó được gọi là cái này. Tóm lại, hãy nghĩ về các đối tượng là sự kết hợp của trạng thái (dữ liệu) và hành vi (các phương thức - tên ưa thích của các hàm trong OOP).

Đây là điều cơ bản tuyệt đối. Có ba khái niệm nữa bạn phải hoàn toàn nắm vững:

Kế thừa - Đây là tất cả về việc sử dụng lại mã.

Đóng gói - Đây là tất cả về việc ẩn việc triển khai khỏi giao diện. Nói một cách đơn giản, mọi thứ phải ở chế độ riêng tư cho đến khi được chứng minh ngược lại.

Tính đa hình - Không quan trọng kiểu của biến tham chiếu mà là kiểu của cá thể thực tế để biết hành vi (phương thức) nào được gọi. Java không dễ dàng để có khái niệm này vì theo định nghĩa, mọi thứ đều là đa hình. .Net giúp bạn dễ hiểu hơn khi bạn quyết định đâu là đa hình và đâu là không, do đó nhận thấy sự khác biệt trong hành vi. Điều này đạt được nhờ sự kết hợp giữa ảo và ghi đè.

Nếu những khái niệm này được hiểu rất rõ, bạn sẽ ổn.

Một mẹo cuối cùng cuối cùng: Bạn đề cập đến những cuốn sách hay nhất. Bạn đã đọc " Thinking in Java " của Bruce Eckel chưa? Tôi giới thiệu cuốn sách này ngay cả với những người bắt đầu với .Net, vì các khái niệm OOP được trình bày rõ ràng.

Trở nên nhanh nhẹn hơn, học thử nghiệm tháng sáu và nghiên cứu về Thiết kế theo hướng miền. Tôi đề xuất cuốn sách Thiết kế theo hướng miền: Giải quyết sự phức tạp trong trái tim của phần mềm mặc dù nó hơi khó ở một số điểm.

Kỹ năng OOP xuất hiện theo thời gian. Đọc 1, 2 ... 10 cuốn sách cũng không cắt được. Thực hành viết một số mã. Nếu bạn đang làm việc trong môi trường lập trình ... điều đó có thể hữu ích. Nếu không, hãy thử tham gia vào một. Đề nghị phát triển (các) ứng dụng miễn phí. Bạn phải làm bẩn tay. Hãy nhớ rằng ... không có ứng dụng nào là hoàn hảo ngay từ đầu. Đó là lý do tại sao lại có tính toán lại.

Ngoài ra ... đừng để bị OOP cuốn đi quá nhiều ... nó sẽ âm ỉ theo thời gian. Lo lắng về việc phát triển các ứng dụng đầy đủ chức năng.

Hãy thử lập trình bằng Self , một trong những ngôn ngữ OO thuần túy nhất. Trên thực tế, nó thuần khiết đến mức nó thậm chí không có các lớp mà chỉ có các đối tượng. Nó cũng không có biến, trường, tĩnh, thuộc tính, chỉ có phương thức. Một điều thú vị nữa là mọi đối tượng trong hệ thống cũng là một đối tượng trên màn hình và ngược lại.

Một số bài báo thú vị về Bản thân là Xây dựng ứng dụng dựa trên nguyên mẫu bằng cách sử dụng SELF 4.0 (hướng dẫn về Bản thân), Bản thân: Sức mạnh của sự đơn giản và tổ chức chương trình không cần lớp học . Ngoài ra, Bản thân: Đoạn video (Randall B. Smith; Dave Ungar) rất tuyệt vời, có hai nhà thiết kế của ngôn ngữ này giải thích ý tưởng của Self.

Điều này thực sự phù hợp với hầu hết mọi khái niệm, ít nhất là đối với tôi: tìm ngôn ngữ thể hiện thuần túy nhất khái niệm bạn muốn học và chỉ sử dụng nó.

OO cuối cùng đã nhấp cho tôi sau khi tôi cố gắng lập trình một chương trình giống như ngân hàng để xử lý các giao dịch, tính lãi và theo dõi tất cả. Tôi đã làm điều đó khi tôi đang học Java. Tôi khuyên bạn chỉ nên thử nó, hoàn thành nó và sau đó khi bạn hoàn thành, hãy xem xét một giải pháp TỐT và xem bạn có thể làm gì tốt hơn.

Tôi cũng nghĩ rằng các kỹ năng OOP có được chủ yếu nhờ thực hành. Cân nhắc thay đổi công ty của bạn, nếu bạn đã ở đó hơn 3 năm. Chắc chắn, điều này không đúng cho tất cả các công việc, nhưng thường thì một người đàn ông đã quen với các dự án và thực hành tại một công ty và ngừng thăng tiến khi thời gian trôi qua.

Xắn tay áo và code!

Bạn tự nói câu trả lời: luyện tập. Giải pháp tốt nhất cho điều này là phát triển một trò chơi. Sử dụng các khái niệm bạn đã học trong sách ở đó.

Bạn đã đọc chương về OO từ ấn bản đầu tiên của cuốn sách Scott Meyers "C ++ hiệu quả" chưa? Nó không được xuất bản sau này, nhưng đó là một lời giải thích tuyệt vời. Tiêu đề về cơ bản là "nói những gì bạn muốn nói, nghĩa là những gì bạn nói" về các quy ước phù hợp.

Trên thực tế, bạn có thể muốn xem câu trả lời của tôi cho một câu hỏi tương tự ở đây .

HTH

cổ vũ,

Lên kế hoạch cho mọi thứ. Hãy tự hỏi bản thân xem bạn muốn các đối tượng của mình liên quan đến nhau như thế nào và tìm cách thay đổi và mô-đun hóa mọi thứ.

Mã mọi thứ theo cách mà nếu bạn muốn thay đổi 1 đoạn mã, bạn chỉ phải thay đổi 1 đoạn mã đó chứ không phải 50 trường hợp của nó.

OOP không phải là thứ bạn có thể thành thạo bằng cách đọc hàng nghìn cuốn sách. Thay vì bạn phải cảm nhận các khái niệm bên trong. Đọc bất cứ thứ gì nhưng hãy thử cảm nhận những gì bạn đọc. Xây dựng một khái niệm trong tâm trí của bạn và cố gắng khớp những khái niệm đó khi bạn đối mặt với một kịch bản mới. Xác minh và cập nhật các khái niệm của bạn khi bạn khám phá những điều mới.

Chúc may mắn!

bia giúp. nghiêm túc. nằm dài trên một chiếc ghế dài với một tập giấy viết nguệch ngoạc khổ A3, một cây bút và một cốc bia. Nhốt chó, mèo và vợ ở ngoài. Và suy nghĩ về vấn đề trong khi thư giãn. Thậm chí không dám vẽ một API trên đó!

Lưu đồ, thẻ đáp ứng (CRC) và bia (nhưng không quá nhiều) đi một chặng đường dài.

Cách dễ nhất để cấu trúc lại mã là không cần phải làm ngay từ đầu.

http://misko.hevery.com/code-reviewers-guide/

Những quy tắc đơn giản nhỏ đó sẽ giúp bạn trở thành một lập trình viên OO tốt hơn. Hãy tuân thủ các quy tắc một cách tôn giáo khi bạn viết mã và bạn sẽ thấy mã của mình tốt hơn so với cách khác.

Bạn cũng sẽ muốn tìm hiểu các Nguyên tắc vững chắc: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Các nguyên tắc và cách lập trình này gây ra nhiều tranh luận, chúng là cách duy nhất để thực sự viết mã xuất sắc.

Bạn có thể đã viết mã theo cách này và không biết nó-- nếu vậy, thật tuyệt. Nhưng nếu bạn cần một mục tiêu để phấn đấu thì đây là những tiêu chuẩn vàng.

Bỏ cuộc! Tại sao bạn cần OOP đó? Chỉ cần viết một số ứng dụng có thể sử dụng. Không đo lường sử dụng OOP, phương pháp tiếp cận theo thủ tục hoặc chức năng.

Phương pháp tiếp cận bảo vệ nào bạn chọn ngôn ngữ Python nên có thể thực hành được.

Bạn là đối tượng mục tiêu của tôi. Xem kỹ năng xây dựng trong thiết kế OO

Có lẽ điều này có thể giúp ích.