Các lớp đặt tên trở nên suy nhược [đóng]


9

Tôi không chắc đây có phải là đặc điểm OCD hay không, nhưng tôi thấy rằng đôi khi tôi bị chặn hoàn toàn không thể tiếp tục những gì tôi đang làm khi đặt tên một lớp (hoặc hàm hoặc không gian tên, v.v.) mà tôi tin là sẽ được sử dụng bên ngoài của một dự án nhất định. Một API chẳng hạn. Hoặc một thư viện lớp tiện ích.

Nếu việc đặt tên không chính xác (trong suy nghĩ của tôi) thì tôi không thể tiếp tục ... Tôi bị mắc kẹt khi cố gắng đưa ra tên đúng. Tôi đã thử viết những ứng dụng nhỏ sẽ sử dụng nó để xem những cái tên đó trông như thế nào nhưng điều đó dường như không giúp ...

Tôi biết điều đó không quan trọng, và nó chống lại bất kỳ suy nghĩ lập trình nào khi cho rằng bạn sẽ hoàn thành nó ngay từ đầu ... Tôi chỉ cảm thấy bất lực với nó ...

Bất kỳ lời khuyên / ý tưởng sẽ được đánh giá rất cao ...


3
Từ kinh nghiệm của tôi, một khi bạn đã hoàn thành phần thân của lớp, được tái xác nhận, v.v., thì tên của lớp và phương thức bắt đầu rơi vào vị trí của chúng.
Công việc

11
Trích dẫn bắt buộc: Triệu chỉ có hai vấn đề khó khăn trong Khoa học máy tính: vô hiệu hóa bộ đệm và đặt tên mọi thứ. - Phil Karlton
Macke

Cảm giác quen thuộc. Đừng bỏ cuộc, đừng bắt đầu đặt tên thứ "Chung", "Tiện ích", "Người quản lý" và "Người trợ giúp". :)
Arnis Lapsa

Câu trả lời:


10

Theo suy nghĩ của tôi, vấn đề bạn gặp phải không chỉ là tìm ra cách tốt hơn để đưa ra những cái tên hay, mà là đối phó với sự bắt buộc phải làm như vậy. Nếu tôi trung thực, tôi nhận ra một đặc điểm tương tự trong bản thân mình. Tên là quan trọng, sau tất cả, và tôi thích một cái tên hay cho các khái niệm tôi đang làm việc. Tuy nhiên, chúng không phải lúc nào cũng là điều quan trọng nhất.

Dưới đây là một số phương pháp tôi sử dụng để khắc phục loại điều này:

  1. Nhận ra rằng không có giải pháp hoàn hảo, chỉ có giải pháp tốt hơn những giải pháp khác.
  2. Hãy làm việc đầu tiên trước. Điều quan trọng là phải hoàn thành một bài tập lập trình hơn là thực hiện nó một cách hoàn hảo.
  3. Hỏi người khác. Tất cả chúng ta đều có những khu vực mà chúng ta sa lầy, nhưng may mắn thay, những người khác nhau sa lầy ở những nơi khác nhau. Có lẽ ai đó sẽ nghĩ ra một cái tên hay, hoặc nói với bạn rằng nó thực sự không quan trọng.
  4. Đặt giới hạn thời gian. Cho bản thân bạn x phút để làm điều bạn bị treo lên, sau đó tiếp tục.
  5. Hãy tự hứa với bản thân rằng bạn sẽ quay lại sau. Giữ một bản ghi của những điều bạn muốn quay trở lại. Rất nhiều loại vấn đề trở nên rõ ràng hơn khi bạn để chúng một mình. Sau này bạn sẽ nghĩ ra một cái tên hay hơn hoặc bạn sẽ nhận ra rằng nó thực sự không quan trọng.
  6. Nhận ra rằng trong 100 năm nữa, không ai quan tâm.
  7. Làm ngược lại. Đặt cho một lớp học một tên thực sự xấu, và xem những gì sẽ xảy ra. Điều này sẽ xác nhận sự cần thiết phải dành thời gian cho những cái tên hay hơn, hoặc cho bạn thấy nó thực sự quan trọng như thế nào. Ngoài ra, điều này sẽ giúp bạn thoát ra khỏi tâm trí ám ảnh.
  8. Hãy cầu nguyện. Điều này thường làm việc cho tôi.
  9. Giá trị bản thân ngoài những gì bạn làm. Thoát khỏi ý tưởng rằng giá trị của riêng bạn đến từ việc cung cấp sự hoàn hảo. Khi chúng tôi nhận ra rằng chúng tôi có giá trị nội tại, ngoài công việc của chúng tôi, chúng tôi cảm thấy bớt xấu hổ hơn khi chúng tôi không đo lường theo tiêu chuẩn của chính mình.
  10. Tạo từ mới và sử dụng chúng để đặt tên cho các lớp học của bạn, hoặc chỉ mục đích lại những từ cũ. Lập trình là một quá trình sáng tạo và đôi khi những ý tưởng chúng ta nắm bắt lại là những ý tưởng mới. Ý tưởng mới cần tên mới. "EmployeeTransmogrifier" là một tên hoàn toàn hợp lệ cho một lớp.
  11. Hãy xem xét rằng bạn đang cố gắng giải quyết vấn đề sai. Ví dụ, không nên viết API mà không có ý tưởng rất rõ ràng về nhu cầu của người gọi là gì. Nếu bạn giải quyết vấn đề này, vấn đề đặt tên của bạn có thể dễ dàng hơn rất nhiều.
  12. Bữa trưa. Ăn trưa luôn ngon.

4
+1 cho bữa trưa. Rất nhiều người không đặt đủ giá trị khi nghĩ về điều gì khác để giải quyết vấn đề.
unolysampler

Một số điểm tuyệt vời và được
cân nhắc kỹ lưỡng

5

Thứ nhất

Hãy tự hỏi mình câu hỏi "mục đích duy nhất của lớp này là gì?". Không tuân thủ Nguyên tắc Trách nhiệm Đơn lẻ, việc đặt tên các lớp và phương thức trở nên rất khó khăn. Nếu bạn không thể trả lời câu hỏi đó, bạn có thể cần suy nghĩ lại những gì bạn muốn lớp học làm và xem xét tách các mối quan tâm. Điều này sẽ làm cho nó dễ dàng hơn để đặt tên

Thứ hai

Bạn có một mẫu cho cách bạn đặt tên cho các lớp học của bạn? Có lẽ hãy thử nhìn vào một số mẫu đặt tên phổ biến, ví dụ như mẫu, sẽ trở nên dễ theo dõi hơn nhiều khi bạn đã giải quyết SRP ở trên. Lớp của bạn có phân tích cú pháp XML không? Hãy thử XMLParser. Liệu nó phân tích cú pháp XML, tạo các mô hình miền để thể hiện đầu vào, duy trì chúng cho DB và sau đó đăng một thông báo thành công lên Twitter? Hãy thử tái cấu trúc.

Thứ ba

Tôi hiểu bạn đến từ đâu và đã từng ở trong tình huống tương tự trước đây. Có lẽ hãy thử mở lớp của bạn với một số chức năng, với một tên tạm thời để bắt đầu. Với bất kỳ IDE tốt hoặc tái cấu trúc assitant, đổi tên lớp phải là một hành động chỉ bằng một cú nhấp chuột, vì vậy những gì bạn đặt tên cho lớp của bạn ban đầu không cần phải là vĩnh viễn! Điều này sẽ giúp bạn vượt qua khối OCD của bạn và cho thời gian tiềm thức của bạn để xử lý nó thêm một chút.


Cuối cùng và hơi lạc đề

Tôi đã có một khoảnh khắc bóng đèn trong một số công việc tôi đang làm vào một ngày khác, thực hiện một hệ thống không quan trọng và tôi đã dành thời gian chơi đùa với các cách đặt tên khác nhau của các lớp, v.v ... Đặt tên cho giao diện của bạn theo chức năng, đặt tên cho các lớp theo hàm ý cụ thể của chúng ... Ví dụ: bạn có thể muốn có IXMLParser và XMLParser, nhưng điều gì xảy ra khi đầu vào của bạn thay đổi thành JSON? Thay vào đó, hãy thử IInputParser, theo cách đó bạn có thể tạo các lớp cụ thể XMLParser và JSONParser, cả hai đều triển khai IInputParser theo các cách khác nhau.


Đúng, tôi cũng đã có một khoảnh khắc như vậy ... vấn đề là bạn rất giỏi về nó và bạn không bao giờ có thể viết mã dự định, ba luôn là cách bố trí trừu tượng ...
Robin Vessey

1

Đối với tôi, đó thường là một dấu hiệu thiết kế không rõ ràng trong đầu, vì vậy tôi tạo nên một cái tên và dành cho mình một khoảng thời gian (giả sử là 2 phút) để đưa ra một cái tốt hơn, vào cuối thời gian đó, tôi phải sử dụng cái tôi nghĩ ra đầu tiên Barney, Wilma và Fred là những mục yêu thích để bắt đầu. Tôi làm những việc như "BarniesInputParser" Những cái tên rất tệ Tôi phải nghĩ ra một cái tốt hơn hoặc thay đổi chúng sau này. Chúng cũng tệ đến mức chúng là duy nhất, khiến việc tái cấu trúc trở nên tầm thường và an toàn, và bất cứ ai nhìn vào mã không hoàn chỉnh đều có thể thấy ngay lập tức nó không hoàn chỉnh.

Điều quan trọng là trong khi bạn không thêm chức năng, bạn sẽ không cung cấp cho bộ não của mình bất kỳ thông tin mới nào để sử dụng để xác định tên (và làm rõ thiết kế). Tất cả những gì bạn đang làm là lấy lại cùng một đầu vào theo những cách khác nhau.

Hoặc đi pha cà phê. Trước khi bạn đến máy, bạn sẽ có nó ...


thật đáng sợ, tôi biết phần mềm được vận chuyển được đặt tên theo cách đó ... hãy tưởng tượng cố gắng giải thích rằng 5 năm sau, khi bạn là người duy nhất ở công ty vẫn biết "Tim" là ai.
Yaur

0

Tôi đã nhận được điều này từ một người bạn một thời gian trở lại. Viết ra những gì quá trình của bạn phải làm. Chỉ là một câu chuyện ngắn. Sau đó lấy danh từ và biến chúng thành các lớp, động từ thành phương thức và trạng từ thành thuộc tính.


Đó là một bài tập đơn giản, kiểu CS101 để dạy OOAD . Tuy nhiên, nó không đạt được trong bất kỳ hệ thống thực tế nào mà không phải là một giáo sư hoặc tác giả sách giáo khoa.
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.