2010-10-29 12 views
6

Không chắc chắn nếu tiêu đề ghi lại những gì tôi đang cố gắng nói ở đây.Tách đối tượng thành các phần cơ bản nhất của chúng

Khi thiết kế trong OO, tôi phải tách các đối tượng của mình thành các khu vực cụ thể nhất - vì vậy nếu tôi có đối tượng nhà máy liên quan đến việc tạo đối tượng nhưng sau này tôi sẽ tìm cách tạo đối tượng cho một mục đích khác có thể là cùng một đối tượng là nó có giá trị tạo ra một fcatory riêng biệt hoặc chỉ cần thêm vào exsiting.

Nỗi lo lớn nhất của tôi là làm xáo trộn các lớp học với nhiều thứ, hoặc chia nhỏ các đối tượng và pha loãng các dự án của tôi thành một lớp học biển.

Bất kỳ trợ giúp nào?

EDIT:

Tôi đoán trên một mặt lưu ý/sub phần chủ đề của tôi muốn tìm hiểu mức độ granularity bạn nên sử dụng trong một chương trình. Loại, bạn nên đi bao nhiêu?

+0

+1 cho câu hỏi thú vị – posdef

+0

câu hỏi của bạn không thực sự tập trung. Bạn đang nghĩ đến việc tạo lớp học nào? – hvgotcodes

+0

chỉ nói chung .. nhưng nếu bạn muốn các lớp chi tiết hơn theo các mẫu sáng tạo - thay vì các lớp chủ yếu để giữ dữ liệu không phải là phương thức BIG – Julio

Trả lời

4

lo lắng lớn nhất của tôi là bulking lên lớp với tấn công cụ, hoặc đối tượng tách và pha loãng dự án của tôi vào một biển lớp

Đây là một điểm rất hợp lệ và trong bất kỳ thậm chí kích thước hợp lý dự án, cực kỳ khó khăn để có được quyền lên phía trước đặc biệt là bởi vì thực tế, yêu cầu tự phát triển theo thời gian trong hầu hết các trường hợp. Đây là nơi "Tái cấu trúc" đi vào. Bạn thiết kế dựa trên những gì bạn biết tại bất kỳ điểm nào và cố gắng không quá quá nhiều niềm tin vào những gì bạn nghĩ rằng hệ thống CÓ THỂ phát triển.

Vì bạn biết những gì bạn đang xây dựng ngay bây giờ, bạn thiết kế các lớp học của bạn đang cố gắng tận dụng tốt nhất các khái niệm OO - ví dụ như đóng gói/đa hình. Đây là chính nó, giống như những người khác đã ghi nhận là tốt, có thể được nổi tiếng khó khăn để đạt được và đó là nơi kinh nghiệm, cả trong việc thiết kế hệ thống OO cũng như kiến ​​thức về tên miền thực sự có thể có ích.

Thiết kế dựa trên những gì bạn biết -> Build It -> Xem lại nó -> Refactor nó -> Re-thiết kế -> và nó đi và về ..

+0

Yêu câu trả lời này. Rất ít CÓ! những khoảnh khắc đọc nó. Tôi luôn cố gắng nghĩ rằng đây là một điểm mạnh nhưng cũng là điểm yếu. Tôi mãi mãi suy nghĩ nhưng nếu ... Nhưng tôi không có tâm linh, tôi chỉ có thể làm việc với những gì tôi có/biết. Cảm ơn vì điều này, xứng đáng nhiều hơn upvote duy nhất của tôi. – Julio

+1

+1 Đã thăng cấp nó cho bạn. Chỉ cần đọc những tình cảm tương tự này trong một cuốn sách Thiết kế điều khiển tên miền vào ngày khác. – wllmsaccnt

+0

Sách nào? – Julio

1

Tìm mức độ chi tiết và trách nhiệm chính xác là điều khiến thiết kế OOP trở nên khó khăn. Chúng tôi có thể giúp bạn với một trường hợp cụ thể nhưng không phải với bất kỳ điều gì chung này. Nếu có các thuật toán hoặc phương pháp nghiêm ngặt để giải quyết vấn đề này, mọi người đều có thể là một nhà thiết kế OOP.

+1

câu trả lời này là loại những gì tôi đang tìm kiếm .. nó làm cho tôi cảm thấy tốt hơn về những gì tôi đang làm. Rất vui được biết tôi không bỏ lỡ điều gì và vâng, thật khó! – Julio

+1

Nó thực sự chỉ là kinh nghiệm. Khi bạn làm một cái gì đó mà bạn sau đó quyết định là quá phức tạp/unmaintainable/đã xấu "mã mùi" mất một chút thời gian để suy nghĩ về lý do tại sao đó là và những gì gây ra nó để có được như thế. – Flexo

+1

Nhưng sau đó một lần nữa, OOP không khác với các ngành kỹ thuật khác; sau khi tất cả các nhà thiết kế cầu phải quyết định mức độ trừu tượng chính xác. Và cho đến nay, họ thành công hơn nhiều trong việc xác định các yêu cầu và thông số kỹ thuật so với hầu hết các kỹ sư phần mềm. Đây có thể là một điểm đáng chú ý, và để điều tra. – Schedler

1

Quy tắc chung mà tôi thích để quyết định "hiện tại có quá lớn không?" là "tôi có thể giải thích mục đích của nó một cách chính xác không?" Nếu bạn bắt đầu phải giới thiệu các từ và nhiều từ chồn để giải thích các chức năng của một thành phần trong thiết kế của bạn (có thể là lớp, biến thành viên, phương pháp hay bất kỳ thứ gì). .

+0

Là phần thưởng bổ sung, nó cung cấp cho bạn câu đầu tiên của javadoc hoặc bất kỳ hệ thống tài liệu nào bạn đang sử dụng miễn phí! – Flexo

1

Trong trường hợp cụ thể của bạn, nếu bạn đã có đối tượng nhà máy thì Nguyên tắc DRY (Đừng lặp lại) sẽ nói rằng bạn nên tạo một nhà máy khác làm điều tương tự.

Đây có phải là vấn đề thực tế mà bạn phải đối mặt không? Hoặc đơn thuần là nỗi sợ về cách mã của bạn có thể phát triển trong tương lai?

+0

Tôi có thể đã nói những điều tồi tệ trong Q. Tôi đoán tôi sẽ không lặp lại bản thân nó chỉ là một trường hợp để đặt mã, nó có thể được thêm vào một nhà máy exsiting tạo ra các đối tượng thiết kế cho exporing dữ liệu để excel bảng tính. Mặt khác tôi có thể thấy nó cũng có thể có nhà máy riêng của mình để nhập dữ liệu excel. Cả hai nhà máy sẽ sản xuất cùng một đối tượng nhưng các hoạt động bên trong hoàn toàn khác nhau. – Julio

+0

@Franco - từ nhận xét của bạn, có vẻ như các đối tượng mà các nhà máy đó tạo ra là vấn đề thực sự. Nếu bạn chưa làm điều đó, tôi khuyên bạn nên đưa ra một bộ giao diện "hẹp" mô tả chức năng bạn muốn. Từ quan điểm thực hiện, bạn có thể có cùng một đối tượng thực hiện nhiều giao diện (mặc dù hiếm khi có nhu cầu cho điều đó). – Anon

+0

Đây có phải là một ý kiến ​​hay nếu xem xét nhà máy này có khả năng sẽ là nhà máy duy nhất thuộc loại này và không có đối tượng nào khác sử dụng giao diện này. – Julio

0

Nếu bạn đang sử dụng cùng một loại đối tượng để giải quyết các vấn đề khác nhau đáng kể thì bạn có thể cần phải thiết kế lại lớp để tập trung vào việc phân tách các mối quan ngại. Nếu bạn cần một câu trả lời cụ thể hơn, bạn sẽ cần phải cung cấp một ví dụ về một loại lớp cần có chức năng này.


những điều tôi có thể diễn đạt tồi tệ trong Q. Tôi đoán tôi wouldnt được lặp đi lặp lại bản thân mình của nó chỉ nhiều hơn một trường hợp nơi để đặt mã này, nó có thể là thêm vào một exsiting nhà máy mà tạo ra các đối tượng thiết kế để hiển thị dữ liệu cho bảng tính excel. Trên Mặt khác, tôi có thể thấy nó cũng có thể có nhà máy riêng của mình để nhập dữ liệu excel . Cả hai nhà máy sẽ sản xuất cùng một đối tượng nhưng hoạt động bên trong hoàn toàn khác nhau. -

Nếu bạn không làm hoặc có kế hoạch làm bất kỳ lớp trừu tượng nào (phân lớp hoặc sử dụng giao diện), bạn có thể không cần sử dụng mẫu nhà máy. Mẫu nhà máy thường phù hợp nhất để cung cấp các đối tượng của một loại lớp cơ sở hoặc thực hiện một giao diện cụ thể.

0

Cả các nhà máy sẽ sản xuất cùng một đối tượng nhưng các hoạt động bên trong là hoàn toàn khác nhau.

Không chắc chắn nếu tôi đã hiểu chính xác bạn, nhưng điều này giống như một ứng cử viên cho mẫu AbstractFactory.

+0

Từ đọc những nhận xét khác của Franco, tôi nghĩ anh ta có nghĩa là các hoạt động bên trong của các vật thể sau khi chúng được tạo ra hoàn toàn khác ... không chỉ là hoạt động bên trong của cả hai nhà máy. – wllmsaccnt

+0

Vâng, được rồi. Vì vậy, miễn là các đối tượng chia sẻ một giao diện phổ biến thì đó là những gì nhà máy trừu tượng là tất cả về. – Qwerky

Các vấn đề liên quan