Làm thế nào để bạn thiết kế các dự án hướng đối tượng? [đóng cửa]

Tôi đang làm việc trong một dự án lớn (đối với tôi) sẽ có nhiều lớp và sẽ cần mở rộng, nhưng tôi không chắc cách lập kế hoạch cho chương trình của mình và cách các lớp cần tương tác.

Tôi đã tham gia một khóa học về một vài học kỳ trở lại và học được nhiều điều từ nó; như viết UML và dịch các tài liệu yêu cầu thành các đối tượng và các lớp. Chúng tôi cũng đã học các sơ đồ trình tự nhưng bằng cách nào đó tôi đã bỏ lỡ bài giảng hoặc một cái gì đó, chúng không thực sự gắn bó với tôi.

Với các dự án trước đây tôi đã thử sử dụng các phương pháp tôi đã học được từ khóa học nhưng thường kết thúc bằng mã mà ngay khi tôi có thể nói "vâng, nó trông giống như những gì tôi đã nghĩ", tôi không muốn tìm hiểu thêm về muck để thêm vào Các tính năng mới.

Tôi đã có một bản sao Hoàn thành Mã của Steve McConnell mà tôi liên tục nghe thấy rất tuyệt vời ở đây và những nơi khác. Tôi đã đọc chương về thiết kế và dường như không đưa ra thông tin mà tôi đang tìm kiếm. Tôi biết anh ta nói rằng đó không phải là quá trình cắt và sấy khô, mà chủ yếu dựa trên phương pháp phỏng đoán, nhưng dường như tôi không thể lấy tất cả thông tin của anh ta và áp dụng nó vào các dự án của mình.

Vậy bạn phải làm gì trong giai đoạn thiết kế cấp cao (trước khi bắt đầu lập trình) để xác định các lớp bạn cần (đặc biệt là các lớp không dựa trên bất kỳ 'đối tượng trong thế giới thực' nào) và chúng sẽ tương tác với nhau như thế nào?

Cụ thể tôi quan tâm đến các phương pháp bạn sử dụng là gì? Quá trình bạn làm theo thường là gì cho một thiết kế tốt, sạch sẽ đại diện chặt chẽ cho sản phẩm cuối cùng?

Các bước tôi sử dụng cho thiết kế ban đầu (lấy sơ đồ lớp), là:

1. Yêu cầu thu thập. Nói chuyện với khách hàng và đưa ra các trường hợp sử dụng để xác định chức năng mà phần mềm nên có.

2. Soạn một bài tường thuật về các trường hợp sử dụng cá nhân.

3. Đi qua các danh từ tường thuật và làm nổi bật (người, địa điểm, sự vật), như các lớp ứng cử viên và động từ (hành động), như phương pháp / hành vi.

4. Loại bỏ các danh từ trùng lặp và yếu tố ra chức năng phổ biến.

5. Tạo một sơ đồ lớp. Nếu bạn là nhà phát triển Java, NetBeans 6.7 từ Sun có mô-đun UML cho phép lập sơ đồ cũng như kỹ thuật khứ hồi và MIỄN PHÍ. Eclipse (một Java IDE mã nguồn mở), cũng có một khung mô hình hóa, nhưng tôi không có kinh nghiệm với nó. Bạn cũng có thể muốn dùng thử ArgoUML, một công cụ nguồn mở.

6. Áp dụng các nguyên tắc của 3M để tổ chức các lớp học của bạn (đưa ra chức năng chung, xây dựng hệ thống phân cấp, v.v.)

Thêm vào những gì Scott Davies đã nói:

1. Hãy chắc chắn rằng bạn biết chương trình của bạn là gì trước khi bạn bắt đầu. Có gì là chương trình của bạn? Nó sẽ không làm gì? Vấn đề là nó đang cố gắng giải quyết?

2. Bộ trường hợp sử dụng đầu tiên của bạn không nên là một danh sách giặt là của tất cả mọi thứ mà chương trình cuối cùng sẽ làm. Bắt đầu với các trường hợp sử dụng nhỏ nhất mà bạn có thể đưa ra mà vẫn nắm bắt được bản chất của chương trình của bạn là gì. Ví dụ, đối với trang web này, các trường hợp sử dụng cốt lõi có thể đăng nhập , đặt câu hỏi , trả lời câu hỏi và xem câu hỏi và câu trả lời . Không có gì về danh tiếng, bầu chọn hoặc wiki cộng đồng, chỉ là bản chất thô của những gì bạn đang chụp.

3. Khi bạn đến với các lớp tiềm năng, đừng nghĩ về chúng chỉ về danh từ mà chúng đại diện, mà là trách nhiệm của chúng. Tôi đã thấy đây là sự trợ giúp lớn nhất trong việc tìm ra cách các lớp liên quan đến nhau trong quá trình thực hiện chương trình. Thật dễ dàng để đưa ra các mối quan hệ như "một con chó là một con vật" hoặc "một con chó con có một người mẹ." Thông thường khó hơn để tìm ra các mối quan hệ mô tả các tương tác thời gian chạy giữa các đối tượng. Các thuật toán của chương trình của bạn ít nhất cũng quan trọng như các đối tượng của bạn và chúng sẽ dễ dàng thiết kế hơn nếu bạn đánh vần công việc của mỗi lớp là gì.

4. Khi bạn đã có bộ trường hợp và đối tượng sử dụng tối thiểu đó, hãy bắt đầu mã hóa. Nhận một cái gì đó thực sự chạy càng sớm càng tốt, mặc dù nó không làm được gì nhiều và có thể trông giống như tào lao. Đó là một điểm khởi đầu và sẽ buộc bạn phải trả lời các câu hỏi mà bạn có thể viết trên giấy.

5. Bây giờ hãy quay lại và chọn thêm các trường hợp sử dụng, viết ra cách chúng sẽ hoạt động, sửa đổi mô hình lớp của bạn và viết thêm mã. Giống như lần cắt đầu tiên của bạn, hãy thực hiện ít nhất có thể trong khi bạn vẫn có thể thêm một cái gì đó có ý nghĩa. Rửa sạch và lặp lại.

Chỉ hai xu của tôi. Hy vọng nó hữu ích.

Khi tôi có cơ hội, tôi thường sử dụng cái mà tôi gọi là "quy tắc ba lần lặp".

Trong lần lặp đầu tiên (hoặc khởi động), tôi nghĩ ra cách bố trí chung của ứng dụng theo các đối tượng mô hình, các thuật toán và dự kiến ​​( thực sự mong đợi, có thể khôngdự kiến) định hướng trong tương lai. Tôi không viết tài liệu thiết kế, nhưng nếu tôi phải phối hợp nhiều người, tất nhiên cần có một bản phác thảo sơ bộ về thủ tục, cùng với việc phân tích các phụ thuộc và dự đoán về thời gian cần thiết. Cố gắng giữ giai đoạn này ở mức tối thiểu nếu như tôi, bạn thích một phương pháp nhanh nhẹn hơn. Có những trường hợp cần một giai đoạn thiết kế mạnh, đặc biệt là khi mọi thứ được biết và đúng về logic của chương trình của bạn và nếu bạn dự định có nhiều tương tác giữa các tính năng trong mã của bạn. Trong trường hợp này, các trường hợp sử dụng hoặc câu chuyện người dùng cung cấp là một ý tưởng cấp cao tốt, đặc biệt là cho các ứng dụng GUI. Đối với các ứng dụng dòng lệnh và trong các thư viện cụ thể, hãy thử viết "câu chuyện chương trình" trong đó bạn mã hóa thư viện mà bạn phải phát triển và kiểm tra xem nó trông như thế nào.

Sau lần lặp đầu tiên này, bạn sẽ hiểu rõ hơn về cách mọi thứ tương tác, tìm ra các chi tiết và các điểm thô, giải quyết các vấn đề với một miếng băng keo dán. Bạn đã sẵn sàng sử dụng trải nghiệm này để cải thiện, làm sạch, đánh bóng, phân chia những gì quá lớn, kết hợp những gì quá phân mảnh, xác định và sử dụng các mẫu thiết kế, phân tích các tắc nghẽn hiệu suất và các vấn đề bảo mật không cần thiết. Nói chung, tất cả những thay đổi này sẽ có tác động rất lớn đến các bài kiểm tra đơn vị bạn đã viết, nhưng không ảnh hưởng đến các bài kiểm tra chức năng.

Khi bạn hoàn thành lần lặp thứ hai này, bạn sẽ có một viên ngọc nhỏ, được thử nghiệm tốt, tài liệu tốt và được thiết kế tốt. Bây giờ bạn có cả kinh nghiệm và mã để thực hiện lần lặp thứ ba, mở rộng. Bạn sẽ thêm các tính năng mới và các trường hợp sử dụng để cải thiện ứng dụng của bạn. Bạn sẽ tìm thấy các điểm thô và cuối cùng bạn sẽ nhập một lần lặp thứ tư tương tự như lần thứ hai. Rửa sạch và lặp lại.

Đây là cách tiếp cận chung của tôi để thiết kế phần mềm. Nó tương tự như thiết kế xoắn ốc, với các vòng lặp ngắn, ba tháng và các yếu tố phát triển Agile, cho phép bạn tìm hiểu các vấn đề và tìm hiểu phần mềm và lĩnh vực ứng dụng của nó. Tất nhiên, đó là vấn đề về khả năng mở rộng, vì vậy nếu ứng dụng quá lớn để thu hút hàng trăm nhà phát triển, mọi thứ phức tạp hơn một chút so với điều này, nhưng cuối cùng tôi đoán ý tưởng luôn giống nhau, hãy chia et đế chế .

Vì vậy, tóm tắt:

1. Trong lần lặp lại, bạn có thể cảm nhận và học hỏi
2. Trong lần lặp thứ hai, bạn làm sạch sản phẩm của mình và chuẩn bị cho tương lai
3. Trong lần lặp ba, bạn thêm các tính năng mới và tìm hiểu thêm
4. goto 2

Nguồn thú vị nhất mà tôi biết về vấn đề này là Phần D của Xây dựng phần mềm hướng đối tượng, Ấn bản thứ 2 của Bertrand Meyer.

Phần D: Phương pháp hướng đối tượng: áp dụng tốt phương pháp

19: Về phương pháp luận, 20: Mẫu thiết kế: hệ thống tương tác đa bảng, 21: Nghiên cứu trường hợp kế thừa: "hoàn tác" trong một hệ thống tương tác, 22: Cách tìm các lớp , 23: Nguyên tắc thiết kế lớp, 24: Sử dụng tốt kế thừa , 25: Các kỹ thuật hữu ích, 26: Ý thức về phong cách, 27: Phân tích hướng đối tượng, 28: Quy trình xây dựng phần mềm, 29: Dạy phương pháp

Thật thú vị, chương 22. Làm thế nào để tìm các lớp có sẵn trực tuyến.

Điều đó lặp đi lặp lại nhưng hoàn toàn đúng - hiểu dữ liệu của bạn.

Đối với OOP, các lớp của bạn nên mô tả các mẩu thông tin nổi bật và cách chúng tương tác.

Nếu bạn có một mô hình tinh thần mô tả tốt hành vi và thời gian tồn tại của dữ liệu, bạn sẽ có một chuyến đi dễ dàng sắp xếp các lớp học của mình.

Đây chỉ đơn giản là một phần mở rộng của: Biết chính xác những gì bạn đang cố gắng làm.

Hãy thử sử dụng phát triển theo hành vi. Sẽ khó để từ bỏ thói quen cũ của bạn, nhưng tôi đã thấy rằng BDD thực sự là lựa chọn tốt nhất của bạn khi phát triển trong thế giới thực.

http://behaviour-driven.org/

Vấn đề với các dự án lớn là bạn không thể giám sát tất cả các tương tác giữa các thành phần. Do đó, điều quan trọng là giảm sự phức tạp của dự án. Sơ đồ lớp và trình tự quá chi tiết cho giai đoạn thiết kế này.

Trước tiên hãy thử suy nghĩ từ mức độ trừu tượng cao hơn. Hãy suy nghĩ về các thành phần chính và trách nhiệm của chúng (giao diện của chúng với các thành phần khác), xem xét một số mẫu kiến ​​trúc để lấy cảm hứng (không, không phải mẫu thiết kế, đây là các mức quá thấp! MVC và Multi-Tier là các ví dụ mẫu kiến ​​trúc). Đối với các dự án lớn hợp lý, một khung nhìn như vậy nên có khoảng 3-5 thành phần.

Chỉ sau đó bạn phóng to vào một thành phần nhất định và cố gắng thiết kế đó. Bây giờ chúng tôi đang ở cấp độ của các mẫu thiết kế và sơ đồ lớp. Cố gắng tập trung vào phần này của dự án, nếu bạn thấy bạn cần thêm trách nhiệm cho một trong các thành phần khác, chỉ cần thêm nó vào danh sách tài liệu / việc cần làm của bạn. Đừng lãng phí thời gian suy nghĩ về những tác động vào thời điểm này chúng thay đổi quá nhanh, hãy xem lại khi thiết kế chắc chắn hơn.

Bạn không cần thiết kế đầy đủ từng thành phần tại thời điểm này, mặc dù có lẽ nên có một đoạn mã thực hiện giao diện các thành phần chưa được thực hiện và tạo ra các phản hồi đơn giản nhưng hữu ích. Bằng cách này, bạn có thể bắt đầu phát triển (và thiết kế) một thành phần tại một thời điểm và kiểm tra nó ở mức độ hợp lý.

Tất nhiên, khi các thành phần mới được hoàn thành, bạn nên kiểm tra cách chúng (và nếu) chúng tích hợp với nhau trước khi tiếp tục.

Nói tóm lại: Lấy nguyên tắc che giấu thông tin và OO, và kéo nó lên một cấp độ khác!

Tái bút: Làm rất nhiều bản phác thảo trong khi thiết kế, nó giống như kiến ​​trúc thực sự!

PPS: Cố gắng tiếp cận vấn đề từ các góc độ khác nhau, suy nghĩ bên ngoài hộp (mặc dù hộp có thể là cách để đi), thảo luận với các đồng nghiệp có thể rất hữu ích cho việc này ... và bạn có điều gì đó để nói về bữa trưa.

Kỹ thuật tôi đã sử dụng trong các dự án thực tế với thành công hợp lý là Thiết kế hướng trách nhiệm, lấy cảm hứng từ cuốn sách của Wirfs-Brock.

Bắt đầu với những câu chuyện của người dùng cấp cao nhất và với các đồng nghiệp, trong một bảng trắng, phác họa các tương tác cấp cao mà họ ngụ ý. Điều này giúp bạn có ý tưởng đầu tiên về các mô-đun lớn là gì; và một hoặc hai lần lặp thẻ CRC cấp cao như chơi, bạn nên ổn định một danh sách các thành phần chính, những gì chúng làm và cách chúng tương tác.

Sau đó, nếu bất kỳ trách nhiệm nào lớn hoặc phức tạp, hãy tinh chỉnh các mô-đun đó xuống cho đến khi bạn có những thứ đủ nhỏ và đơn giản để trở thành đối tượng, bằng cách phát ra các tương tác bên trong mô-đun cho từng hoạt động chính được xác định bởi các tương tác cấp cao hơn .

Biết khi nào nên dừng lại là vấn đề phán đoán (chỉ đi kèm với kinh nghiệm).

Mẫu thiết kế

Mẫu thiết kế sáng tạo

Singleton - Đảm bảo rằng chỉ có một phiên bản của một lớp được tạo và Cung cấp một điểm truy cập toàn cầu cho đối tượng.

Factory (Phiên bản đơn giản hóa của Phương thức Factory) - Tạo các đối tượng mà không để lộ logic khởi tạo cho máy khách và Tham chiếu đến đối tượng mới được tạo thông qua một giao diện chung.

Phương thức xuất xưởng - Xác định giao diện để tạo đối tượng, nhưng hãy để các lớp con quyết định lớp nào sẽ khởi tạo và Tham chiếu đến đối tượng mới được tạo thông qua giao diện chung.

Tóm tắt Factory - Cung cấp giao diện để tạo một họ các đối tượng liên quan, mà không chỉ định rõ ràng các lớp của chúng.

Trình tạo - Xác định một thể hiện để tạo một đối tượng nhưng để các lớp con quyết định lớp nào sẽ khởi tạo và Cho phép kiểm soát tốt hơn quá trình xây dựng.

Nguyên mẫu - Chỉ định các loại đối tượng cần tạo bằng cách sử dụng một thể hiện nguyên mẫu và tạo các đối tượng mới bằng cách sao chép nguyên mẫu này.

Các mẫu thiết kế hành vi

Chuỗi Responsibiliy - Nó tránh việc đính kèm người gửi yêu cầu đến người nhận, đưa ra cách này cho các đối tượng khác khả năng xử lý yêu cầu. - Các đối tượng trở thành một phần của chuỗi và yêu cầu được gửi từ đối tượng này sang đối tượng khác trong chuỗi cho đến khi một trong các đối tượng sẽ xử lý nó.

Lệnh - Đóng gói một yêu cầu trong một đối tượng, Cho phép tham số hóa các máy khách với các yêu cầu khác nhau và Cho phép lưu các yêu cầu trong hàng đợi.

Thông dịch viên - Đưa ra một ngôn ngữ, xác định cách biểu diễn cho ngữ pháp của nó cùng với một trình thông dịch sử dụng biểu diễn để diễn giải các câu trong ngôn ngữ / Ánh xạ một miền thành ngôn ngữ, ngôn ngữ theo ngữ pháp và ngữ pháp theo thiết kế hướng đối tượng phân cấp

Iterator - Cung cấp một cách để truy cập các phần tử của một đối tượng tổng hợp một cách tuần tự mà không làm lộ đại diện bên dưới của nó.

Người hòa giải - Xác định một đối tượng gói gọn cách thức một tập hợp các đối tượng tương tác. Người hòa giải thúc đẩy sự ghép đôi lỏng lẻo bằng cách ngăn không cho các đối tượng đề cập đến nhau một cách rõ ràng và nó cho phép bạn thay đổi sự tương tác của họ một cách độc lập.

Người quan sát - Xác định sự phụ thuộc một-nhiều giữa các đối tượng để khi một đối tượng thay đổi trạng thái, tất cả các phụ thuộc của nó sẽ được thông báo và cập nhật tự động.

Chiến lược - Xác định một họ các thuật toán, gói gọn từng cái và làm cho chúng có thể hoán đổi cho nhau. Chiến lược cho phép thuật toán thay đổi độc lập với các khách hàng sử dụng nó.

Phương thức mẫu - Xác định bộ xương của thuật toán trong một thao tác, trì hoãn một số bước cho các lớp con / Phương thức mẫu cho phép các lớp con xác định lại các bước nhất định của thuật toán mà không để chúng thay đổi cấu trúc của thuật toán.

Khách truy cập - Đại diện cho một hoạt động được thực hiện trên các thành phần của cấu trúc đối tượng / Khách truy cập cho phép bạn xác định một hoạt động mới mà không thay đổi các lớp của các thành phần mà nó hoạt động.

Đối tượng Null - Cung cấp một đối tượng như một đại diện thay thế cho việc thiếu một đối tượng thuộc một loại nhất định. / Mẫu đối tượng Null cung cấp hành vi không làm gì thông minh, ẩn các chi tiết khỏi các cộng tác viên của nó.

Mẫu thiết kế kết cấu

Bộ điều hợp - Chuyển đổi giao diện của một lớp thành giao diện khác mà khách hàng mong đợi. / Adaptor cho phép các lớp hoạt động cùng nhau, điều đó không thể vì giao diện không tương thích.

Cầu - Soạn các đối tượng thành các cấu trúc cây để thể hiện hệ thống phân cấp toàn bộ. / Hợp chất cho phép khách hàng xử lý các đối tượng riêng lẻ và các thành phần của các đối tượng một cách thống nhất.

Kết hợp - Soạn các đối tượng thành các cấu trúc cây để thể hiện hệ thống phân cấp toàn bộ. / Hợp chất cho phép khách hàng xử lý các đối tượng riêng lẻ và các thành phần của các đối tượng một cách thống nhất.

Trang trí - thêm các trách nhiệm bổ sung linh hoạt cho một đối tượng.

Fly weight - sử dụng chia sẻ để hỗ trợ một số lượng lớn các đối tượng có một phần trạng thái bên trong của chúng trong đó phần khác của trạng thái có thể thay đổi.

Memento - nắm bắt trạng thái bên trong của một đối tượng mà không vi phạm đóng gói và do đó cung cấp một phương tiện để khôi phục đối tượng về trạng thái ban đầu khi cần thiết.

Proxy - cung cấp một Placeholder Giữ chỗ cho một đối tượng để kiểm soát các tham chiếu đến nó.

Tôi muốn giới thiệu cho bạn sử dụng BlueJ và ActiveWriter để tìm hiểu và cũng để phát triển sự hiểu biết tốt về các đối tượng. Cuốn sách được đề nghị cũng là một tài nguyên tốt đẹp.

Từ Wikipedia :

BlueJ là Môi trường phát triển tích hợp cho ngôn ngữ lập trình Java, được phát triển chủ yếu cho mục đích giáo dục, nhưng cũng phù hợp để phát triển phần mềm quy mô nhỏ.

Ngoài ra, nó sử dụng UML và đối với tôi, đó là một nguồn tài nguyên tốt để hiểu một số điều về mô hình hóa các đối tượng.

văn bản thay thế http://www.ryanknu.com/ryan/bluej.png

ActiveWriter là một công cụ để mô hình hóa các thực thể và quan hệ, nó cũng tạo mã và dễ dàng thực hiện các thay đổi. Nó sẽ giúp bạn tiết kiệm thời gian và cho sự phát triển nhanh nhẹn là rất phù hợp.

_{(nguồn: altinoren.com )}

Trước hết - thiết kế nên xuất phát từ tâm hồn của bạn. Bạn phải cảm nhận nó bởi mỗi sợi của bạn. Tôi thường đi bộ xuống trong hai hoặc ba tháng trước khi tôi bắt đầu làm bất cứ điều gì, Chỉ cần đi bộ xuống đường (thực sự). Và suy nghĩ. Đi bộ là một thiền tốt, bạn biết đấy. Vì vậy, nó cho phép bạn tập trung tốt.

Thứ hai - chỉ sử dụng OOP và các lớp khi phân cấp đối tượng tự nhiên tồn tại. Đừng 'vặn vẹo' nó một cách giả tạo. Nếu không có hệ thống phân cấp nghiêm ngặt tồn tại (như trong hầu hết các ứng dụng kinh doanh) - hãy sử dụng các thủ tục / chức năng hoặc ít nhất chỉ sử dụng các đối tượng làm vùng chứa dữ liệu với các bộ truy cập bị cô lập.

Và cuối cùng - hãy thử đọc điều này: Thuật toán của tư duy sáng tạo

Chỉ cần trích dẫn http://www.fysh.org/~katie/computing/methodologists.txt

Và cốt lõi của RUP là một khu vực nhỏ nơi bạn phải sử dụng tài năng thiết kế OO .... nếu bạn không có chúng, nó giống như một phương pháp để chạy 100m.

"Bước 1: viết về việc chạy thật nhanh. Bước 2: Đi và vẽ sơ đồ đường đua. Bước 3: đi và mua quần short lycra thật chặt. Bước 4: chạy thật, thật, thật nhanh. Bước 5: vượt qua trước "

Đó là bước 4 khó khăn nhất. Nhưng nếu bạn chú trọng vào 1,2,3 và 5 thì không ai có thể nhận ra và sau đó bạn có thể kiếm được rất nhiều tiền khi bán phương pháp này để trở thành vận động viên nghĩ rằng có "bí mật" là 100m người chạy qua

Bạn đã hỏi câu hỏi mà rất nhiều tác giả sử dụng để viết một cuốn sách. Có một số phương pháp và bạn nên chọn một phương pháp có vẻ "đẹp nhất" đối với bạn.
Tôi có thể giới thiệu cuốn sách "Thiết kế hướng tên miền" của Eric Evans. Ngoài ra, hãy kiểm tra trang web dddcommunity.org .

Tôi nghĩ rằng câu trả lời ở đây nên rất khác nhau tùy thuộc vào kinh nghiệm thực tế của anh chàng hỏi.

Nếu bạn chỉ có một hoặc hai năm kinh nghiệm làm việc thì bạn phải đi đến điểm đó là: làm thế nào để bạn đạt đến điểm bạn thực sự biết dữ liệu của mình và hiểu chính xác những gì bạn đang cố gắng làm?

Vâng, nếu bạn đã làm việc trong thế giới thực hơn 5 năm thì bạn sẽ chọn giữa bất kỳ mô hình hoặc kỹ thuật quy trình phát triển phần mềm nào.

Nhưng bạn không có kinh nghiệm bằng cách chỉ đọc sách. Bạn nên học bằng cách làm việc trong một nhóm tốt dưới sự lãnh đạo tốt.

Nếu điều đó là không thể thì bạn chỉ nên làm một mình. Bắt đầu lặp đi lặp lại bằng cách mã hóa một đoạn mã có lẽ rất khó chịu, học các lỗi của bạn, bỏ tất cả, mã hóa một mã tốt hơn và cứ thế.

Bạn sẽ học được rất nhiều về codebase của bạn. Các công cụ là công cụ, họ sẽ không dạy gì cho bạn.

Nếu bạn có chuyên môn về dự án, bạn sẽ làm việc như ngân hàng. Thật dễ dàng để cấu trúc các đối tượng của bạn và bạn biết làm thế nào những cải tiến đó đến mỗi ngày.

Nếu bạn không có chuyên môn đó làm việc với một người có chuyên môn đó và chuyển đổi những ý tưởng đó thành chi tiết kỹ thuật.

Nếu bạn bối rối về cách cấu trúc thiết kế dự án của bạn. BLINDLY theo cuốn sách "lập trình viên thực dụng". Tôi đã ở trong tình trạng tương tự trước đây, hãy thử đọc một chương từ cuốn sách đó. bạn sẽ thấy sự khác biệt, Nó sẽ thay đổi cách bạn nghĩ như một nhà phát triển phần mềm.

1. học & làm chủ các mẫu thiết kế.
2. Tiếp theo, tìm hiểu về Thiết kế hướng tên miền
3. Sau đó, tìm hiểu thu thập yêu cầu

Tôi đã tham gia một khóa học về một vài học kỳ trở lại và học được nhiều điều từ nó; như viết UML và dịch các tài liệu yêu cầu thành các đối tượng và các lớp. Chúng tôi cũng đã học các sơ đồ trình tự nhưng bằng cách nào đó tôi đã bỏ lỡ bài giảng hoặc một cái gì đó, chúng không thực sự gắn bó với tôi.

4. Bạn biết về bước 3. Bạn cần nắm vững nó. Ý tôi là, thông qua rất nhiều thực hành để làm cho nó trở thành bản chất thứ hai của bạn. Đó là bởi vì phương pháp bạn học, chỉ đơn giản là chống lại cách chúng ta từng có. Vì vậy, bạn cần phải thực sự làm chủ nó. Nếu không, bạn sẽ luôn thấy mình quay trở lại cách làm việc ban đầu. Điều này giống như Test Driven Process, nơi có rất nhiều nhà phát triển java từ bỏ nó sau một vài lần thử. Trừ khi họ hoàn toàn làm chủ nó, nếu không, đó chỉ là gánh nặng cho họ

5. Viết các trường hợp sử dụng, đặc biệt là cho khóa học thay thế. Khóa học thay thế chiếm hơn 50% thời gian phát triển của chúng tôi. Thông thường, khi PM của bạn giao cho bạn một nhiệm vụ, ví dụ, tạo một hệ thống đăng nhập, anh ta sẽ nghĩ rằng nó sẽ thẳng tiến, bạn có thể mất 1 ngày để hoàn thành nó. Nhưng anh ta không bao giờ tính đến việc bạn cần xem xét, 1. nếu khóa người dùng sai mật khẩu, 2. nếu khóa người dùng sai mật khẩu 3 lần, thì sao, nếu người dùng không nhập tên người dùng, v.v. Bạn cần liệt kê chúng ra, và đưa nó cho Thủ tướng của bạn, yêu cầu anh ta sắp xếp lại thời hạn.

Tôi sợ rằng đây không phải là một câu trả lời mà mọi người thích nghe . Dù sao, hãy để tôi nêu ý kiến ​​của tôi.

OOP nên được xem là một trong những mô hình, không phải là mô hình ưu việt. OOP tốt cho việc giải quyết một số loại vấn đề, như phát triển thư viện GUI. Nó cũng phù hợp với phong cách phát triển phần mềm thường được theo sau bởi các công ty phần mềm lớn - một nhóm các nhà thiết kế hoặc kiến trúc sư ưu tú đưa ra thiết kế phần mềm trong các sơ đồ UML hoặc một số phương tiện tương tự khác và một nhóm ít giác ngộ hơn nhà phát triểndịch thiết kế đó thành mã nguồn. OOP mang lại rất ít lợi ích nếu bạn làm việc một mình hoặc với một nhóm nhỏ lập trình viên tài năng. Sau đó, tốt hơn là sử dụng một ngôn ngữ hỗ trợ nhiều mô hình và sẽ giúp bạn đưa ra một nguyên mẫu nhanh chóng. Python, Ruby, Lisp / Scheme, vv là những lựa chọn tốt. Nguyên mẫu là thiết kế của bạn. Sau đó, bạn cải thiện về điều đó. Sử dụng mô hình tốt nhất để giải quyết vấn đề trong tầm tay. Nếu cần, tối ưu hóa các điểm nóng với các tiện ích mở rộng được viết bằng C hoặc một số ngôn ngữ hệ thống khác. Bằng cách sử dụng một trong những ngôn ngữ này, bạn cũng có được thể mở rộngmiễn phí, không chỉ ở cấp độ lập trình viên mà còn ở cấp độ người dùng. Các ngôn ngữ như Lisp có thể tự động tạo và thực thi mã, có nghĩa là người dùng của bạn có thể mở rộng ứng dụng bằng cách viết các đoạn mã nhỏ, bằng ngôn ngữ mà chính phần mềm được mã hóa! Hoặc nếu bạn chọn viết chương trình bằng C hoặc C ++, hãy xem xét việc nhúng trình thông dịch cho một ngôn ngữ nhỏ như Lua. Hiển thị các chức năng như các plugin được viết bằng ngôn ngữ đó.

Tôi nghĩ rằng, hầu hết thời gian OOP và OOD tạo ra phần mềm là nạn nhân của thiết kế quá mức.

Tóm lại, cách ưa thích của tôi để viết phần mềm là:

1. Sử dụng một ngôn ngữ năng động.
2. Viết thiết kế (nguyên mẫu) bằng chính ngôn ngữ đó.
3. Nếu cần, tối ưu hóa các khu vực nhất định bằng C / C ++.
4. Cung cấp khả năng mở rộng bằng cách thông dịch viên của ngôn ngữ thực hiện.

Tính năng cuối cùng cho phép phần mềm dễ dàng thích ứng với các yêu cầu cụ thể của người dùng (bao gồm cả bản thân tôi!).

Tôi sử dụng Test-Driven Design (TDD). Viết bài kiểm tra đầu tiên thực sự giúp bạn dẫn đến một thiết kế sạch sẽ và chính xác. Xem http://en.wikipedia.org/wiki/Test-driven_development .

Tìm hiểu các mẫu thiết kế . Đó là cuộc cách mạng cá nhân của tôi trong hai năm qua về OOP. Lấy một quyển sách. Tôi muốn giới thiệu cho bạn cái này:

Mẫu thiết kế đầu tiên

Nó có trong Java nhưng nó có thể mở rộng ra bất kỳ ngôn ngữ nào.

Thành thật mà nói, một bước tốt sẽ trở lại và xem xét biểu đồ dòng chảy và sơ đồ tuần tự. Có rất nhiều trang web tốt chỉ cho bạn cách làm điều đó. Tôi thấy nó là vô giá khi nhìn vào cách tôi muốn chia nhỏ một chương trình thành các lớp vì tôi biết chính xác những gì chương trình cần nhập, tính toán và xuất ra và mỗi bước có thể được chia thành một phần của chương trình.

Như đã trả lời trong quy trình công việc bạn làm theo để thiết kế phần mềm bạn sắp viết là gì?

Một kỹ thuật hữu ích là liên kết mô tả vấn đề độc đáo của bạn với một cái gì đó bạn có thể tìm thấy trong thế giới thực. Ví dụ, bạn đang mô hình hóa một hệ thống chăm sóc sức khỏe phức tạp sẽ gây bão trên toàn thế giới. Có bất kỳ ví dụ nào bạn có thể dễ dàng gọi để mô hình hóa điều này?

Thật. Quan sát cách nhà thuốc bên sẽ hoạt động, hoặc phòng của bác sĩ.

Đưa vấn đề tên miền của bạn xuống một cái gì đó dễ hiểu với bạn; một cái gì đó mà bạn có thể liên quan.

Sau đó, khi "người chơi" trong miền bắt đầu xuất hiện rõ ràng và bạn bắt đầu lập mô hình mã của mình, hãy chọn cách tiếp cận mô hình "nhà cung cấp-người tiêu dùng", tức là mã của bạn là "nhà cung cấp" của mô hình và bạn là "người tiêu dùng ".

Liên quan đến tên miền và hiểu nó ở mức cao là phần quan trọng của bất kỳ thiết kế nào.

Trong cuộc phiêu lưu của tôi về thiết kế cấu trúc lớp, tôi đã nhận thấy rằng việc bắt đầu bằng cách viết một số mã giả là rất hữu ích. Điều đó có nghĩa là: Tôi bắt đầu với việc viết bằng văn bản, một số đoạn mã chung của ứng dụng ở mức cao nhất, chơi với nó và khám phá các yếu tố xuất hiện - trên thực tế, các yếu tố mà tôi - với tư cách là một lập trình viên - muốn sử dụng. Đó là một điểm khởi đầu rất tốt để thiết kế cấu trúc chung của các mô-đun và các tương tác của chúng. Sau vài lần lặp, toàn bộ cấu trúc bắt đầu trông giống như một hệ thống đầy đủ các lớp. Đó là một cách rất linh hoạt để thiết kế các phần của mã. Bạn có thể gọi nó là một thiết kế theo định hướng lập trình viên.