Bạn sẽ làm gì nếu khách hàng yêu cầu bạn không sử dụng lập trình hướng đối tượng?

Tôi đang viết một chương trình mô phỏng hoạt động của kiến ​​trong lưới (PDF). Con kiến ​​có thể di chuyển xung quanh, nhặt đồ và thả đồ.

Vấn đề là trong khi hành động của kiến ​​và vị trí của mỗi con kiến ​​có thể được theo dõi bởi các thuộc tính lớp một cách dễ dàng (và chúng tôi có thể dễ dàng tạo ra nhiều trường hợp của những con kiến ​​đó), khách hàng của tôi nói rằng vì anh ta có nền tảng về lập trình chức năng nên anh ta muốn mô phỏng được thực hiện bằng cách sử dụng lập trình chức năng.

Để rõ ràng, các từ gốc từ máy khách chỉ là "không có lớp", nhưng không phải là "lập trình chức năng". Vì vậy, tôi cho rằng anh ta không có nghĩa là lập trình chức năng và tôi có thể làm điều đó một cách bắt buộc. Ngoài ra, tôi không có kinh nghiệm trước đó trong lập trình chức năng.

Tuy nhiên, tôi nghĩ sẽ có ích khi tập trung vào câu hỏi này đặc biệt là về một yêu cầu lập trình chức năng thay vì chỉ đơn giản là "thực hiện nó một cách bắt buộc".

Làm thế nào bạn sẽ xử lý tình huống này? Bạn có cố gắng thuyết phục khách hàng của mình rằng sử dụng lập trình hướng đối tượng sẽ gọn gàng hơn nhiều, cố gắng làm theo những gì anh ta yêu cầu và đưa cho anh ta mã chất lượng kém, hoặc làm một cái gì khác?

Mã hướng đối tượng không theo định nghĩa sạch hơn và ngược lại, mã không OO không theo định nghĩa crappy. Mặc dù dường như có một ánh xạ hướng đối tượng khá rõ ràng cho vấn đề cụ thể này, tôi vẫn khuyên bạn nên thử phương pháp lập trình chức năng nào. Cung cấp cho nó bức ảnh đẹp nhất của bạn, cố gắng giải quyết vấn đề theo phong cách lập trình chức năng tốt nhất mà bạn có thể tập hợp được và bạn có thể học được điều gì đó bạn không mong đợi.

Bạn đề cập rằng máy khách được sử dụng để lập trình bằng ngôn ngữ chức năng, có thể anh ta có lý do rằng anh ta yêu cầu bạn viết mã theo kiểu chức năng. Bạn nên hỏi anh ấy tại sao .

Có lẽ anh ta có ý định giữ mã và tự duy trì nó sau này.

Hơn nữa, tôi không nghĩ hai lựa chọn là làm theo kiểu OO hoặc viết mã ngu ngốc như bạn đã đề cập. Chắc chắn việc viết mã chức năng trong một ví dụ như thế này có thể khó hơn, đặc biệt là nếu bạn chỉ có kinh nghiệm về ngôn ngữ hướng đối tượng, nhưng nếu khách hàng sẵn sàng chờ thêm một thời gian nữa để bạn có thể tăng tốc với phong cách chức năng thì nó sẽ không ' T đau lắm khi hỏi anh mà.

Tôi sẽ hỏi anh ta tại sao anh ta muốn mã theo kiểu chức năng và nếu thời gian không phải là vấn đề quá lớn, tôi sẽ yêu cầu thêm một số ngày để tăng tốc với lập trình chức năng. (tin mừng khi được trả tiền để học!)

Nếu tất cả những điều khác không giải thích rằng bạn sẽ mất ít thời gian hơn để làm điều đó theo kiểu OO.

Bạn có biết rằng lập trình chức năng không chỉ có nghĩa là "lập trình không có lớp"?

Xem bài viết Wikipedia về nó cho schtick đầy đủ, nhưng tóm lại ...

Trong khoa học máy tính, lập trình chức năng là một mô hình lập trình coi việc tính toán là việc đánh giá các hàm toán học và tránh trạng thái và dữ liệu đột biến. Nó nhấn mạnh việc áp dụng các chức năng, trái ngược với phong cách lập trình mệnh lệnh, trong đó nhấn mạnh đến những thay đổi về trạng thái.

Lập trình hàm là một mô hình lập trình, giống như OO là một mô hình lập trình.

Nếu nền của bạn ở trong OO, thì tôi có thể thấy bạn muốn tất cả những con kiến ​​của bạn trở thành đối tượng như thế nào. Mặt khác, nếu bạn mô phỏng một trang trại kiến ​​với hàng triệu con kiến, OO và truyền tin nhắn có thể trở nên không hiệu quả.

May mắn cho bạn, Python có các công cụ tuyệt vời để lập trình chức năng (điều quan trọng nhất là các hàm là các đối tượng hạng nhất.)

Lập trình hàm Python

Giải thích cho khách hàng của bạn rằng nếu anh ta muốn lập trình chức năng, anh ta nên thuê một người chuyên về việc đó. Lập trình chức năng rất khác so với OOP, và bạn sẽ nhầm nếu bạn nghĩ rằng bạn có thể dễ dàng chọn nó và cung cấp một giải pháp phức tạp có chất lượng cao.

Có một quan niệm sai lầm phổ biến rằng "OO" hoàn toàn trái ngược với "chức năng". Những điều này có thể đi đôi với nhau rất tốt. Trong ví dụ của bạn, tôi đoán một "Ant" có thể được mô hình hóa tốt như một kiểu dữ liệu trừu tượng, có thể được triển khai thẳng bằng cách sử dụng các lớp và các đối tượng. Chuyển đổi giữa các "trạng thái Ant" có thể được mô hình hóa một cách tự nhiên bằng cách sử dụng các hàm, điều này sẽ dẫn bạn đến một cách tiếp cận chức năng cho đến khi lớp "Ant" của bạn là một loại không thay đổi.

Và lưu ý rằng "các đối tượng" có thể được hoán đổi bởi khái niệm chức năng của việc đóng cửa, vì các đối tượng là sự đóng cửa của người nghèo là đối tượng của người nghèo là ... ;-):

https://stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean

https://stackoverflow.com/questions/501023/closures-and-objects

Sau khi nói chuyện với khách hàng, nếu anh ta vẫn muốn theo cách của anh ta, bạn có thể làm một công việc chuyên nghiệp hoặc nếu bạn không thể thì bạn sẽ không nhận hợp đồng hoặc tìm cách thoát khỏi nó.

Sản xuất "mã tào lao" chỉ vì bạn không đồng ý sẽ rất thiếu chuyên nghiệp.

1. Tại sao tất cả chúng ta đều cho rằng khách hàng biết sự khác biệt giữa lập trình hàm và mệnh lệnh? Rất nhiều người không biết tên hoặc chi tiết cụ thể của các mô hình lập trình không OO và sẽ dễ dàng trao đổi các thuật ngữ như "thủ tục" "bắt buộc" và "chức năng".

2. Đừng đi bộ như thế nào người khác bảo bạn đi bộ trừ khi bạn tin rằng bạn nên đi bộ như vậy. Do đó, nếu bạn không tin rằng lập trình chức năng là phù hợp thì đừng tự đặt ra thất bại hoặc thực hiện một dự án nửa vời.

3. Nếu khách hàng viết thông số kỹ thuật thì thực hiện thông số kỹ thuật, nếu không bạn viết thông số kỹ thuật và thực hiện thông số kỹ thuật của bạn .

4. Chiến lược tốt nhất để tác động đến quyết định của khách hàng là làm cho lựa chọn không mong muốn trở nên đắt hơn đáng kể. Nó hoạt động mọi lúc.

5. Nếu bạn là chuyên gia (liên quan đến khách hàng), thì bạn sẽ có thể thuyết phục họ.

6. Để thực sự biết khách hàng có điểm hợp lệ hay không, bạn cần có thêm kinh nghiệm về lập trình chức năng, để bạn có thể tự tin bắn hạ nó hoặc nhận ra rằng sự thiên vị của bạn đối với OO là do thiếu kinh nghiệm của bạn.

7. Tại sao không làm cả hai cách sau đó để cho khách hàng thấy cả hai triển khai và quyết định cái nào dễ bảo trì hơn. Chỉ cần tính tất cả những điều này vào ước tính dự án của bạn để bạn có thể tận hưởng thời gian học tập trong khi bạn được trả tiền.

Trước khi làm phiền thêm nữa, tôi chắc chắn rằng cả hai bạn đang nói về cùng một điều. Bạn có thể hỏi anh ấy khi phần mềm 'hướng đối tượng' với anh ấy. Sine anh ấy nói rằng đó không phải là chuyên môn chính của anh ấy, có thể là anh ấy có một số ý tưởng sai lệch.

Ví dụ, nhiều người có thể xem xét

class C {
public:
  C();
  void f( int );
  void g();
};

là một cách tiếp cận hướng đối tượng cổ điển, nhưng

struct C;
void construct( C ** );
void f( C *obj, int arg);
void g( C *obj );

không (mặc dù cả hai đều hướng đối tượng như nhau theo định nghĩa "dữ liệu cổ điển cùng với các chức năng hoạt động trên nó" định nghĩa).

Bạn có muốn thuyết phục khách hàng của mình rằng sử dụng lập trình hướng đối tượng sẽ sạch hơn nhiều không?

Tôi nghĩ bạn cần giáo dục bản thân nhiều hơn về các mô hình lập trình. Mã được lập trình hướng đối tượng không nhất thiết phải sạch hơn và trên thực tế, nó không được áp dụng phổ biến. Ngoài ra, một lập trình viên hướng đối tượng tốt biết cách làm việc tốt bằng cách sử dụng một mô-đun thủ tục / mô-đun (Với các mô hình chức năng và khai báo, khó hơn một chút, nhưng không quá khó để một lập trình viên giỏi đến - thông qua việc đọc và suy luận - đến một giải pháp FP / Tuyên bố chấp nhận được.)

Bạn gần như không bao giờ không thể, tôi nhắc lại, bạn gần như không thể hiểu rõ về thời điểm và cách sử dụng Định hướng đối tượng mà không hiểu rõ về lập trình thủ tục và mô đun. OO không chỉ đơn thuần là khai báo các lớp và hệ thống phân cấp thừa kế.

Hoặc bạn sẽ cố gắng làm theo những gì anh ta yêu cầu và cung cấp cho anh ta mã ngu ngốc?

Nếu bạn không thể viết mã tốt theo thủ tục, tôi nghi ngờ bạn có thể viết mã tốt theo cách hướng đối tượng. Giai đoạn. Tôi không cố gắng phán xét ở đây, nhưng điều này phải được khẳng định.

Định hướng đối tượng là một phần mở rộng của lập trình thủ tục và mô đun. Định hướng đối tượng chỉ đơn giản cung cấp cho bạn các công cụ, khi được sử dụng một cách thích hợp, cung cấp cho bạn các cơ chế tốt hơn để xử lý các vấn đề đóng gói, khớp nối, gắn kết và tái sử dụng / mở rộng mã.

Nhưng tất cả những vấn đề đó không phải là cố hữu và duy nhất đối với OO. Chúng tồn tại trong mã thủ tục / mô-đun (và trong các mô hình khác cho vấn đề đó.) Đây là loại vấn đề phức tạp, ở chính cốt lõi của nó, không phụ thuộc vào mô hình. Nếu bạn không thể xử lý chúng mà không có keo OO, thì bạn không thể xử lý chúng bằng nó.

=========

Quay trở lại câu hỏi ban đầu của bạn, về việc có nên cố gắng thuyết phục khách hàng của bạn. Nó phụ thuộc. Như poster Sean McMillan đã nói, nếu khách hàng chỉ đơn giản là cố gắng quản lý vi mô nỗ lực phát triển cho một số chương trình nghị sự (đọc, chính trị văn phòng), hãy bỏ đi. Những người thực hiện các dự án phá hoại đó để đổ lỗi cho người khác, hoặc thúc đẩy một chương trình nghị sự cụ thể. Bạn không muốn tham gia vào đó.

OTH, có thể có những lý do khác cho yêu cầu như vậy. Nhiều cửa hàng nhúng, dù đúng hay sai, chọn đặt nhiều ràng buộc cho những gì bạn có thể làm với C ++ (chẳng hạn, không có phương pháp ảo, không có ngoại lệ.) Đôi khi, nó được thực hiện theo kiểu giật đầu gối. Một số lần khác, có những lý do kỹ thuật hợp lệ để làm như vậy.

Vì vậy, bạn cần hiểu lý do tại sao khách hàng muốn tránh mã OO. Và nếu bạn có thể phỏng đoán rằng không có chương trình nghị sự chính trị (không có cờ đỏ), thì bạn nên làm điều chuyên nghiệp để làm, đơn giản là làm mã theo thủ tục / mô-đun, và làm tốt công việc đó.

Thực sự không có lý do gì để cung cấp mã crappy, độc lập với mô hình lập trình. Nếu bạn không thể tạo mã chấp nhận được với một mô hình, bạn chắc chắn không thể tạo mã được chấp nhận nói chung.

Bạn đang trộn lẫn các cấu trúc dữ liệu và lập trình hướng đối tượng (một sự nhầm lẫn phổ biến trong thế giới bị nhiễm OO này)

Nếu tất cả những gì bạn cần làm là "theo dõi các thuộc tính dữ liệu" trong cấu trúc dữ liệu và sửa đổi chúng thì hầu như bất kỳ ngôn ngữ nào được tạo ra sau thập niên 70 sẽ có suppot tốt cho nó, OO hoặc không.

Những thứ dễ làm hơn trong OO là rawfly

• Kế thừa dựa trên lớp (dễ dàng tạo một lớp mới giả vờ là lớp cũ)
• Đa hình dựa trên lớp (dễ dàng thêm các loại kiến ​​mới vào mô phỏng sau đó)

Nếu bạn không có nhu cầu cấp thiết về một trong những điều này thì về cơ bản, bất kỳ mô hình lập trình nào cũng nên giải quyết vấn đề này mà không gặp quá nhiều vấn đề.

khách hàng của tôi nói rằng vì anh ta có một nền tảng về lập trình chức năng, anh ta muốn mô phỏng được thực hiện bằng lập trình chức năng.

(Đây là một ví dụ khác về một vấn đề xã hội bị nhầm lẫn với vấn đề kỹ thuật / thiết kế.)

Có hai khả năng ở đây:

1. Khách hàng của bạn đang mong đợi có thể lấy mã bạn đã viết và adabpt hoặc tự duy trì nó sau khi bạn viết xong. Nếu vậy, bạn nên biết nhiều hơn về "kiểu nhà" - chức năng so với OO chỉ là phần nổi của tảng băng chìm. Bạn sẽ cần phải giới hạn bản thân trong một phong cách lập trình mà khách hàng của bạn hiểu, hoặc bạn sẽ cần giáo dục khách hàng của mình theo những phong cách bạn thích. (Một lần, tôi được yêu cầu xây dựng một ứng dụng web với CGI, mà không sử dụng templating hoặc thư viện vì khách hàng có thể muốn thực hiện thay đổi.)

2. Khách hàng của bạn đang cố gắng kiểm soát sự phát triển vì một số chương trình nghị sự. Đây là một túi đầy điên rồ mà bạn không muốn làm gì với. Nếu bạn thực sự cung cấp một phần mềm "chìa khóa trao tay", khách hàng không nên quan tâm nếu nó được làm từ chuột hamster chạy trên bánh xe, miễn là nó hoạt động một cách đáng tin cậy. Cho phép bản thân được vi mô theo cách này chỉ là yêu cầu đau đớn.

Tùy thuộc vào bạn để quyết định bạn đang ở trong tình huống nào và hành động phù hợp.

Umm ... tôi có phải là người duy nhất ở đây nghĩ rằng "đây rõ ràng là một công việc / bài tập thử nghiệm" không? .

Thứ nhất - bản chất bài tập là loại "học thuật" về bản chất (mô phỏng một khía cạnh hành vi của loài kiến).

Thứ hai - một yêu cầu thực hiện các yêu cầu bằng cách sử dụng (hoặc tránh) một mô hình lập trình rất cụ thể có mùi của "khách hàng", người có thể đọc mã và đưa ra các xác nhận đó.

Nếu đây là trường hợp, tốt hơn bạn nên làm những gì được yêu cầu của bạn - đó sẽ là trải nghiệm học tập khá tốt và nếu bạn có thể làm điều đó, bạn sẽ học được rất nhiều trong quá trình ...

Nếu đây không phải là trường hợp, bạn thực sự nên tự hỏi mình và / hoặc khách hàng cho lý do về việc chuyển nhượng. Nếu lý luận là vững chắc, thì hãy làm điều đó - bạn sẽ học và bạn sẽ trở thành một lập trình viên tốt hơn cho trải nghiệm. Ai biết được - bạn thậm chí có thể học cách thích phong cách chức năng hơn OO.

Nếu lời giải thích còn thiếu, thì tất cả các cược đã tắt .. Tôi không thể khuyên bạn nên làm gì.

Bạn có thể muốn thử bất kể thực hiện các yêu cầu trong ngôn ngữ / phong cách chức năng hoặc bạn có thể lịch sự từ chối lời đề nghị nếu bạn cảm thấy điều gì đó tanh.

Điều chính là - một khi bạn hiểu được động lực đằng sau các yêu cầu, quá trình hành động thích hợp sẽ trở nên rõ ràng.

EDIT: Sau khi xem qua đường chéo vào tệp PDF được tham chiếu, các thuật toán được mô tả ở đó chắc chắn có vẻ phù hợp với phong cách chức năng hơn là OO

Có một số khía cạnh tốt trong yêu cầu của họ để sử dụng lập trình chức năng:

1. Bạn có một khách hàng, đó luôn là một dấu hiệu tốt
2. Khách hàng hy vọng bạn sẽ rất giỏi trong những gì bạn đang làm. Đây là lý do tại sao họ yêu cầu lập trình chức năng. Vì vậy, tổ chức bán hàng của bạn đang làm tốt công việc hoặc bạn đang yêu cầu mức giá rất cao cho dịch vụ của mình.
3. Tổ chức khách hàng có một số người biết lập trình chức năng là một điều tốt và sẽ lớn trong tương lai

Nhưng cũng có một số dấu hiệu đáng báo động:

1. Bạn dường như không được chuẩn bị để thực hiện nó trong lập trình chức năng. Bạn đã hơi lỗi thời trong các kỹ năng của mình và không thể theo kịp các thay đổi.
2. Hoặc khách hàng đang mong đợi bạn trở thành lập trình viên tốt hơn bạn thực sự. Điều này có nghĩa là bạn có thể cần phải hạ cấp yêu cầu của họ cho đến khi bạn có thể thực hiện đúng.

Phân biệt các câu trả lời trên có thể OO không phải là giải pháp tốt nhất trong trường hợp khách hàng có thể có quan điểm.

Hãy xem AI Challenge mà mô hình một số các hành vi nêu chi tiết trong câu hỏi ở đây http://aichallenge.org và sau đó hãy nhìn vào sự đa dạng của các gói khởi động - http://aichallenge.org/starter_packages.php/ nhất là những ngôn ngữ tôi sẽ không đặt trong mô hình OO.

Bạn đã không viết gì về ngôn ngữ lập trình, đó là điều quan trọng nhất ở đó. Sự khác biệt giữa OOP và lập trình chức năng không chỉ là cách tổ chức mã mà là chính ngôn ngữ. Khi xảy ra đồng thời cao, ngôn ngữ chức năng Erlang đang được sử dụng và nó có lợi thế rất cao so với Java (nó được sử dụng ví dụ như trò chuyện trên Facebook). Giải pháp OOP đơn giản có thể thất bại vì vấn đề hiệu suất.

Khách hàng ở đây là trường đại học, vì vậy ngôn ngữ không chỉ là vấn đề về hiệu năng / cấu hình, mã cũng có thể được sử dụng cho công việc giáo khoa với sinh viên hoặc nghiên cứu riêng. Vì vậy, 'thuyết phục' khách hàng chọn mô hình khác theo ý kiến ​​của tôi không áp dụng ở đây. Đây là hoặc bạn có thể giải quyết công việc hoặc bạn không thể (và vì vậy, bạn không nên thực hiện dự án đó).

Khách hàng nói "nhảy", câu trả lời của bạn là: __ _ ?

Đối với tôi, tôi sẽ cố gắng thuyết phục nếu nó có ý nghĩa (dự án mới), nhưng tôi cũng có một khách hàng với ứng dụng VB6 cũ 10 năm mà tôi thỉnh thoảng nâng cấp ... sẽ không thuyết phục được họ

'Kiểm tra chéo' khách hàng của bạn một chút (theo cách không đối đầu):

Khách hàng có thực sự biết sự khác biệt giữa OOP và lập trình chức năng không? Là mối quan tâm / yêu cầu của khách hàng là hợp pháp?

Nếu 'Có': Nếu bạn đủ điều kiện, hãy làm những gì họ muốn và lấy tiền của bạn. Nếu bạn không đủ điều kiện, hãy nói với họ như vậy và để họ quyết định phải làm gì.

Khác: hi-tail nó ra khỏi đó!

double dist(Point p1, Point p2) 
{
  //return distance
}

Chức năng này là chức năng miễn là nó không đọc / ghi bất cứ điều gì bên ngoài chức năng. Nếu hàm chạm vào một biến lớp thì nó sẽ không còn là "hàm". Ưu điểm của phong cách chức năng là không có thêm lỗi từ trạng thái thay đổi hoặc không hợp lệ. Một lượng lớn các hàm chỉ là các công thức toán học. Đó là lập trình chức năng một cách ngắn gọn.

BTW bạn có thể kết hợp một phong cách chức năng trong một thiết kế dựa trên đối tượng hoặc định hướng. Ví dụ, hai biến "Điểm" là các đối tượng có trạng thái. Và chức năng vẫn là chức năng! Yay !!