Làm thế nào bạn có được thực hành tốt cho các thiết kế OOP của bạn? [đóng cửa]


12

Tôi nhận ra rằng tôi gặp khó khăn khi tạo ra các thiết kế OOP. Tôi đã dành nhiều thời gian để quyết định xem thuộc tính này có được đặt chính xác thành lớp X không.

Ví dụ: đây là một bài đăng có vài ngày: /codereview/8041/how-to-improve-my-factory-design

Tôi không bị thuyết phục về mã của tôi. Vì vậy, tôi muốn cải thiện thiết kế của mình, mất ít thời gian hơn để tạo ra nó.

Làm thế nào bạn học cách tạo ra các thiết kế tốt? Một số cuốn sách mà bạn có thể giới thiệu cho tôi?


Trình độ hiện tại của bạn là gì? Tôi cho rằng bạn biết về các mẫu thiết kế?
ACNB

Trên thực tế, tôi hoàn toàn không bắt đầu đọc một số trong số đó trong khóa học PluralSight
Darf Zon

1
Một trong những cuốn sách có ảnh hưởng nhất trong thiết kế phần mềm là '' Các mẫu thiết kế: Các yếu tố của phần mềm hướng đối tượng có thể tái sử dụng ''. Nó vẫn đáng đọc, mặc dù bây giờ nó hơi cũ. Bạn cũng có thể bắt đầu đọc [ en.wikipedia.org/wiki/Software_design_potype [ ( wikipedia bài viết). Những mẫu thiết kế phần mềm này không chỉ cung cấp cho bạn một giải pháp tốt cho các vấn đề phổ biến, mà còn là một phần của thuật ngữ chuyên nghiệp hiện nay.
ACNB

1. viết - 2. xem lại (bao gồm đọc tài liệu và trang web như P.SE) - 3. tái cấu trúc - 4. lặp lại
HorusKol

không có sự thay thế cho kinh nghiệm, không có sự cắt giảm ngắn nào đối với loại kiến ​​thức này

Câu trả lời:


14

Thiết kế hệ thống là một trong những điều mà bạn chỉ có thể làm tốt hơn bằng cách làm. Tất nhiên, nó giúp ích một chút để đọc về thiết kế tốt - cuốn sách thiết kế hướng đối tượng chung được đề xuất là Mẫu thiết kế của Gang of Four : Các yếu tố của phần mềm hướng đối tượng có thể tái sử dụng . Ngoài ra còn có các cuốn sách khác về các mẫu và nguyên tắc thiết kế cho các loại hệ thống khác nhau và trong các lĩnh vực khác nhau.

Tốt nhất là để người khác tham gia. Sau khi bạn tạo một thiết kế, hãy trình bày (các) vấn đề bạn đang giải quyết và thiết kế cho người khác để đánh giá quan trọng. Lắng nghe phản hồi của họ và có một cuộc đối thoại với họ, tập trung vào lý do tại sao bạn đưa ra quyết định mà bạn đã làm. Khi bạn đang thực hiện giải pháp, bạn sẽ nhận ra các vấn đề khác với thiết kế của mình. Hãy lưu ý những điều này và học hỏi từ họ. Nó cũng có thể là một ý tưởng tốt để làm việc với những người khác để xem xét việc thực hiện theo thiết kế và các yêu cầu, và có một cuộc thảo luận quan trọng về lý do tại sao bạn đã làm những việc bạn đã làm.

Mặc dù tôi thường thấy tốt nhất khi ngồi xuống trực tiếp với người khác, các câu hỏi thiết kế cụ thể có thể được hỏi về vấn đề này trên Lập trình viên. Ngoài ra còn có các trang web Stack Exchange để đánh giá mã và câu hỏi triển khai .


4

Từ vẻ ngoài của câu hỏi về codereview mà bạn đã hỏi, bạn đang ở giai đoạn lạm dụng nó. Tôi nghĩ đó là một vấn đề khá phổ biến trong số những người khám phá ra tầm quan trọng của thiết kế tốt.

Nó thực sự là một bước tự nhiên và thậm chí có thể cần thiết với bất kỳ kỹ năng nào bạn chọn. Khi bạn bắt đầu học một cái gì đó, bạn càng nâng cao kiến ​​thức về một kỹ năng và bạn càng áp dụng nó, kết quả của bạn càng tốt và dường như bạn đang đi thẳng để thành thạo. Vấn đề là, mục tiêu mới của bạn không phải là chất lượng kết quả của bạn, mà là bạn đã tích lũy được bao nhiêu kiến ​​thức về kỹ năng của mình.

Làm chủ thực sự một kỹ năng liên quan đến sự hiểu biết khi nào nên sử dụng nó và khi nào không. Lạm dụng kỹ năng đó có lẽ là cách duy nhất để phát triển sự hiểu biết như vậy. Chắc chắn, bạn có thể đọc về điều này, nhưng đọc không thay thế cho kinh nghiệm.

Đối với một điều, đọc về các mẫu thiết kế là một khởi đầu tồi tệ IMHO. Đọc về các nguyên tắc thiết kế OO, chẳng hạn như RẮNGRASP là tốt hơn. Sau khi làm quen với chúng, nghiên cứu các mẫu thiết kế phổ biến là một ý tưởng tốt, bởi vì bạn sẽ thấy những nguyên tắc đó có thể được áp dụng như thế nào để hình thành các thành ngữ cụ thể.

Người ta khẳng định rằng khi các mẫu xuất hiện trong việc sử dụng ngôn ngữ, thì ngôn ngữ đó thực sự thiếu một tính năng. Trong khi tuyên bố này là rất triệt để, có rất nhiều sự thật trong đó. Do đó tôi sẽ đề nghị, bạn nhìn và chơi xung quanh với các ngôn ngữ khác để hiểu rõ hơn về các khái niệm bạn đang tìm kiếm và cũng để tìm hiểu về các khái niệm mới. Một danh sách rút gọn sẽ là Squeak, Ruby và Lisp.
Đối với Danh sách, đề xuất cá nhân của tôi là Cấu trúc và Giải thích các Chương trình Máy tính , đã dạy tôi rất nhiều về thiết kế, bằng cách cho tôi thấy người ta có thể tạo ra các giải pháp mạnh mẽ cho các vấn đề phức tạp như thế nào, ít hơn là trừu tượng rõ ràng và (de) sáng tác trong một cách từ trên xuống.

Vì vậy, đây là những gì tôi đề nghị:

  1. viết mã (và cố gắng hiểu điều gì làm cho nó xấu)
  2. đọc mã (và cố gắng hiểu những gì làm cho nó tốt)
  3. trao đổi kiến ​​thức với người khác. đưa ý tưởng của bạn để thử nghiệm.

Đây là lời khuyên tuyệt vời! Tôi hoàn toàn ở điểm áp dụng kiến ​​thức mẫu thiết kế của mình, như có thể thấy trong cuộc thảo luận của tôi với Kevin ở đây
TheSilverBONS

3

Như những người khác đã đề cập, bạn sẽ chỉ nhận được tốt với thực hành và kinh nghiệm. Thực sự không có nhiều phím tắt bạn có thể thực hiện.

Thực tế là bạn nhìn lại những thứ của bạn và bạn không thích những gì bạn đã viết, đã đưa bạn lên trước đường cong so với nhiều người khác trong nghề nghiệp của chúng tôi. Trong khi bạn đang cố gắng cải thiện bản thân, phần còn lại chúng tôi làm việc với những người sẽ viết hàm 500 dòng với 20 tham số, tất cả được chuyển qua tham chiếu và 15 trong số đó là [vào / ra] và những người đó nghĩ rằng họ là bom. bởi vì họ có mớ hỗn độn đó để làm việc

Khi nói đến thiết kế phần mềm, nó không phải là màu đen và trắng, thiết kế là tốt hay xấu. Cho dù bạn có bao nhiêu kinh nghiệm, bạn sẽ quay lại một số mã cũ của bạn và nghĩ, "tôi đã hút thuốc gì khi tôi viết cái này?" Điều quan trọng là đánh giá liên tục mọi thứ và thường xuyên trải qua các bài tập suy nghĩ để đánh giá điều gì làm cho mã tốt tốt và mã xấu thành xấu.

Cuối cùng, mặc dù không có gì thay thế thực hành, nhưng luôn luôn nên đọc blog / sách / trang web này bởi vì những người khác sẽ chỉ ra những quan điểm khác nhau mà bạn có thể không xem xét.

Để bắt đầu, tôi muốn giới thiệu những cuốn sách này:

  • Nguyên tắc, mô hình và thực tiễn nhanh nhẹn trong C # - Bản thân tôi là 3/4. Một trong những điểm chính mà tác giả đưa ra và tôi đồng ý 100% với điều đó, đừng bắt đầu giải quyết vấn đề bằng cách tìm kiếm một mẫu thiết kế để áp dụng. Giữ mọi thứ đơn giản nhất có thể và phát triển mã thành một mẫu, nếu sự thay thế bắt đầu trở nên phức tạp hơn thế.
  • Các mẫu thiết kế đầu tiên - Tôi chưa đọc cuốn sách này và trong IMO, nhiều loạt Head First được nhắm mục tiêu cụ thể cho những người mới tham gia vào lĩnh vực này. Vì vậy, họ có xu hướng ở phía đơn giản hơn, nhưng tôi đã nghe / đọc nhiều phản hồi tốt từ những người khác về cuốn sách đó

1
+1: "Giữ mọi thứ đơn giản nhất có thể" ... "Phát triển mã thành một mẫu ..."
kevin cline

1

Thiết kế phía trước không bao giờ tốt như thiết kế ngoài. Chỉ cần kiểm tra, mã, và cấu trúc lại. Khi mọi thứ trở nên xấu xí, và bạn không chắc chắn làm thế nào để dọn sạch nó, thì hãy xem liệu một số mẫu thiết kế sẽ giúp ích. Thực hành điều này trong một thời gian và ngay sau đó các nhà phát triển khác sẽ hỏi làm thế nào bạn đưa ra các thiết kế sạch như vậy.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.