Có phải là một ý tưởng tốt để thiết kế một kiến ​​trúc kiến ​​trúc rằng các lớp Giao diện người dùng có thể được thay thế bằng giao diện dòng lệnh?

Trong Code Complete trang 25, người ta nói rằng có thể dễ dàng thay thế các lớp giao diện người dùng thông thường bằng một dòng lệnh.

Biết lợi thế của nó để thử nghiệm, những vấn đề nó có thể mang lại là gì?

Liệu công việc làm thêm này có thực sự được đền đáp cho các dự án web và di động? Những gì về các dự án vừa và nhỏ; làm quy tắc tương tự áp dụng? Điều gì nếu nó làm cho thiết kế của bạn phức tạp hơn?

Không thể sử dụng lại chức năng trong các giao diện khác nhau (ví dụ GUI vs CLI vs REST) ​​không phải lúc nào cũng cần thiết và cho phép sử dụng lại một cách tình cờ cho một hệ thống, vì những người khác tìm ra cách mới để tương tác với nó.

Điều này có một vài nhược điểm cần được cân nhắc:

1. Nó sẽ yêu cầu các lớp trừu tượng bổ sung (đôi khi thậm chí là các bậc). Mặc dù có các lớp này là thực hành kỹ thuật tốt, chúng có thêm chi phí phát triển, hiểu rằng điều đó có thể không dẫn đến giảm nỗ lực trong các lĩnh vực khác (ví dụ: bảo trì, tái sử dụng, thử nghiệm) vì vậy đáng để suy ngẫm một chút về nó.
2. Dòng chảy tối ưu cho phương tiện có thể là khủng khiếp đối với người khác. Nếu chức năng được thiết kế để hỗ trợ GUI, nó có thể quá chát cho web . Không phải tất cả các chức năng là đáng giá trong mọi phương tiện.
3. Có một cái bẫy trong việc cố gắng xác định một trình chuyển đổi chung giữa các dịch vụ và giao diện người dùng, do đó, người ta có thể xác định hợp đồng dịch vụ và tự động lấy (hoặc càng nhiều càng tốt) giao diện người dùng cho tất cả các phương tiện. Nhiều dự án đã lãng phí quá nhiều nỗ lực cố gắng xây dựng các khung như vậy và thêm mọi tùy chỉnh có thể vào nó khi các yêu cầu thay đổi.

Phải nói rằng, theo kinh nghiệm của tôi, việc thực hiện các lớp như vậy luôn kết thúc bằng nỗ lực. Trong một vài trường hợp, tôi đã quản lý để triển khai các hệ thống đúng hạn vì cuối cùng chúng tôi phải trao đổi phương tiện truyền thông (ví dụ từ tích hợp Dịch vụ Web sang UI) một vài tuần trước ngày đáo hạn.

Hoàn toàn ngoài việc thử nghiệm, lợi thế rõ ràng của phương pháp này là nó sẽ làm cho dự án của bạn có thể tự động hóa và có thể viết được . Nếu tôi có thể gửi các dòng lệnh đến một chương trình, tôi có thể viết một tập lệnh để thực hiện các tác vụ phức tạp dễ dàng hơn (và đáng tin cậy hơn!) Hơn là tôi có thể tạo một macro để tự động hóa điều tương tự trên GUI.

Tất nhiên, việc đó có thực sự đáng làm hay không, tất nhiên, phụ thuộc hoàn toàn vào việc bạn có nhiều người dùng muốn tự động hóa chương trình của bạn hay không.

Đó không phải là công việc làm thêm, chỉ là công việc khác nhau . Nếu bạn làm đúng, không những nó sẽ không làm cho nó phức tạp hơn, nó sẽ làm cho nó đơn giản hơn bởi vì nó sẽ buộc bạn phải tách rời thiết kế của bạn. Cho dù bạn có thực sự thực hiện CLI hay không, thiết kế của bạn sẽ tốt hơn để làm cho nó có thể làm như vậy.

Một lợi thế chính mà dường như không được đề cập đến là việc có thể thực hiện điều này khá nhiều thực thi việc tách rời nghiêm ngặt UI khỏi mã cơ bản. Một lợi thế chính của điều này là nó có nghĩa là nếu bạn cần thay đổi đáng kể GUI (giả sử các tiêu chuẩn iOS thành tiêu chuẩn OSX hoặc một công cụ đồ họa khác), đó là tất cả những gì bạn cần thay đổi, vì mã cơ bản không phụ thuộc vào cách bố trí của UI. Không thể , bởi vì nếu nó là, các công cụ dòng lệnh sẽ không hoạt động.

Ngoài ra, có thể tự động hóa các bài kiểm tra là một lợi thế chính.

Vâng, nó hầu như luôn luôn là một ý tưởng tốt.

Nếu bạn làm theo cách tiếp cận này, bạn sẽ không có khả năng truy cập dữ liệu hoặc logic nghiệp vụ trong cùng một luồng với GUI và đằng sau một số trình xử lý GUI. Lý do này một mình là đáng đầu tư vào.

Tôi nghĩ nó là một ý tưởng hay. Ngoài ra, việc có thể viết một giao diện dòng lệnh thứ hai, cuối cùng chứng minh logic nghiệp vụ hoàn toàn tách rời với bất kỳ kiến ​​trúc máy chủ ứng dụng cụ thể nào.

Mối nguy hiểm duy nhất tôi thấy khi làm điều này là để đến một phần nhất định trong giao diện người dùng, người dùng thường phải đi qua các phần khác của giao diện người dùng.

Trường hợp như nhà phát triển chỉ có thể thực hiện UI trực tiếp. Tôi đã thấy các tình huống mà nhà phát triển không thể tái tạo vấn đề người dùng cho đến khi họ thực sự sử dụng sản phẩm.

Vì vậy, yếu tố đó là tốt khi tạo ra các bài kiểm tra.

Không. Lời khuyên khủng khiếp.

Đó là một chút yagni (Bạn sẽ không cần nó).

Hiển thị giao diện dòng lệnh không giống như cấu trúc ứng dụng của bạn theo cách hỗ trợ kiểm tra đơn vị hoặc tuân thủ bất kỳ phần nào của RẮN hoặc bất kỳ thực hành lập trình nào tôi khuyên dùng.

Nó không hoạt động đối với bất kỳ giao diện người dùng nào không phù hợp với giao diện dòng lệnh. MS Paint là một ứng dụng thực sự đơn giản, nhưng trong mọi tình huống, bạn sẽ thấy lợi ích như thế nào khi có thể kiểm soát nó từ một dòng lệnh?

Nó sẽ không giúp bạn thực hiện kịch bản. Nó thực sự sẽ cản trở bất kỳ tiến bộ theo hướng đó.

Điều tích cực duy nhất là nó xuất hiện ở trang 25, vì vậy ít nhất bạn sẽ nhận được một cảnh báo rằng phần còn lại của cuốn sách có thể, ... có mùi. Tôi đã đọc nó từ lâu và không thích nó, vì vậy tôi thiên vị.

Dựa trên những gì Mason Wheeler đã nói, việc có thể tương tác với một ứng dụng thông qua một dòng lệnh giúp bạn dễ dàng tự động hóa các tác vụ.

Điều này đặc biệt hữu ích trong thử nghiệm.

Để đưa ra một ví dụ thực tế, nếu tôi muốn chạy thử nghiệm tự động trên một ứng dụng, tôi có thể muốn cài đặt ứng dụng tự động. Để làm điều này, tôi có thể truyền vào các tham số sau, "myApplication.exe / quietinstall".

Tôi có thể lập trình nó để khi tôi chỉ định công tắc dòng lệnh này, một cài đặt được thực hiện âm thầm trong nền mà không cần trình cài đặt GUI. Bất kỳ đầu vào nào cho trình cài đặt (chẳng hạn như thư mục cài đặt) có thể được chọn từ một tệp XML.

Lấy một ví dụ khác. Microsoft Test Manager GUI (đi kèm với Visual Studio) cho phép người dùng khởi chạy các lần chạy thử từ giao diện GUI của mình, nhưng cũng cung cấp giao diện dòng lệnh để thực hiện điều tương tự (sử dụng kết hợp các công tắc và đầu vào dòng lệnh). Điều này có nghĩa là tôi có thể kết hợp một tập lệnh PowerShell hoặc DOS để tự động khởi chạy các bài kiểm tra và sau đó tôi có thể tạo một tác vụ theo lịch trình để các tập lệnh được chạy mỗi đêm, có lẽ.

Một số ứng dụng có các công tắc dòng lệnh chỉ định cho một ứng dụng mở với một số tùy chọn nhất định (ví dụ: tôi có thể sử dụng '/ Maximum' để mở ứng dụng trong cửa sổ tối đa hóa).

Có rất nhiều tình huống trong đó giao diện dòng lệnh có thể được sử dụng. Đây chỉ là một vài ví dụ.

Lưu ý cụm từ một lần nữa: "[Đó là một ý tưởng tốt để có thể dễ dàng thay thế các lớp giao diện người dùng thông thường bằng một dòng lệnh một". Điều đó không có nghĩa là bạn phải viết CLI, chỉ là bạn có thể làm điều đó một cách dễ dàng.

Vì vậy, những gì nó nói là UI của bạn nên được tách rời khỏi phần còn lại của mã.

Nó phụ thuộc và khi tôi nói nó phụ thuộc, nó không chỉ là vấn đề có một vài trường hợp cạnh, mà nó phụ thuộc rất nhiều vào ứng dụng và đối tượng mục tiêu. Giả sử rằng chúng ta đang loại bỏ các trò chơi khỏi phương trình thì vẫn còn một loạt các ứng dụng mà bạn có thể đang viết trong đó một lệnh giống như không thể hoặc sẽ không bao giờ được thực hiện. Ngoài đỉnh đầu của tôi, bất kỳ ứng dụng nào nhắm mục tiêu vào môi trường di động (ví dụ: iOS, Android, v.v.) có thể sẽ nằm trong nhóm này.

Với ý nghĩ đó, trong không gian phần mềm chung, bất kỳ ứng dụng nào phụ thuộc nhiều vào trực quan hóa (ví dụ PowerPoint, Maya , v.v.) dường như không bao giờ thấy việc thay thế dòng lệnh được thực hiện. Trong thực tế, trong trường hợp phần mềm đồ họa như Maya, có thể cho rằng một bài tập tinh thần tốt để xác định một phiên bản dòng lệnh đầy đủ và phù hợp sẽ hoạt động như thế nào và có thể không thể làm như vậy từ quan điểm của người dùng. Vì vậy, rõ ràng có những ứng dụng phổ biến chắc chắn có thể gặp phải khi giao diện giống như lệnh không thể nhìn thấy hoặc mong muốn ngay cả khi kịch bản của ứng dụng có thể được mong muốn.

Tiếp theo, nếu chúng ta xem biểu mẫu gợi ý về quan điểm của kiến ​​trúc phần mềm nói chung, tôi có thể thấy nơi nào sẽ hợp lý khi tự hỏi mình "Làm thế nào tôi có thể truy cập tính năng này mà không cần giao diện người dùng?" Nói chung, nếu không có cách nào để làm điều đó và nó không tương tác trực tiếp với người dùng (ví dụ: nhập bằng cử chỉ) thì bạn có thể gặp phải tình huống cần cải thiện kiến ​​trúc tổng thể. Để cho phép dễ dàng kiểm tra, bạn sẽ muốn có thể truy cập trực tiếp vào lệnh mà không cần thông qua giao diện người dùng, mặc dù chúng có thể không được gọi qua một dòng lệnh. Điều này thường có nghĩa là cần phải có một API vững chắc và về mặt lý thuyết, một API tốt sẽ cho phép truy cập thông qua dòng lệnh hoặc giao diện người dùng. Hơn nữa, về lâu dài,

Vào cuối ngày, tôi nghĩ rằng những gì gợi ý đang cố gắng hiểu có ý nghĩa (nghĩa là có một API tốt và xây dựng giao diện người dùng của bạn từ đó) nhưng lựa chọn từ có thể tốt hơn một chút để hiểu ý .

Nó phụ thuộc.

Thông thường chúng tôi phân vùng các chương trình của chúng tôi dưới dạng mô hình / khung nhìn / bộ điều khiển hoặc mô hình / khung nhìn / khung nhìn / mô hình. Có vẻ như mô hình nên cho phép truy cập dòng lệnh, nhưng tôi không chắc chắn về bộ điều khiển. Đương nhiên, quan điểm là những gì đang được thay thế.

Một số khác biệt có thể tồn tại dựa trên chuỗi công cụ. Code Complete là một cuốn sách của Microsoft Press, vậy có lẽ bạn đang sử dụng các công nghệ của Microsoft cho GUI này? Nếu vậy, tôi nghĩ có thể có một hộp kiểm khi bạn tạo ứng dụng để hiển thị giao diện qua COM hoặc DCOM. Đối với một số công nghệ của Microsoft, tôi nghĩ rằng các bảng tài nguyên và thông điệp truyền đi được kết hợp khá chặt chẽ với bất cứ thứ gì mà Phù thủy giúp bạn nhanh chóng tạo nguyên mẫu. Tôi nghĩ rằng nó đang trở nên tốt hơn, nhưng nếu bạn đang duy trì MFC hoặc Biểu mẫu, nó có thể bị tổn thương một chút.

Trong một số trường hợp, chương trình dựa trên GUI của bạn có thể là một trình bao bọc xung quanh giao diện quản lý hoặc có thể có rất ít logic của riêng nó, không có nhiều điều khiển bởi giao diện dòng lệnh. Xây dựng một ứng dụng bảng điều khiển riêng biệt có thể nhanh hơn và vẫn cho phép bạn viết kịch bản, kiểm tra hoặc sử dụng những gì quan trọng.

Điểm quan trọng tôi đoán là đề xuất không phải là một quy tắc. Nếu bạn theo dõi nó, bạn sẽ nhận được thử nghiệm đơn vị và chấp nhận dễ dàng hơn hoặc giao diện quay lại khi bạn hoặc khách hàng có thể thích gõ thay vì nhấp. Nếu nó trả tiền cho chính nó, làm điều đó. Chúc may mắn.

Nó phụ thuộc vào mức độ hữu ích của chương trình dòng lệnh. Một số thứ, như vẽ sơ đồ tuyến đường trên bản đồ hoặc chơi trò chơi 3 chiều, chỉ cần không cho mình mượn giao diện dòng lệnh. Nhưng những thứ khác, như các công cụ hệ thống tốt hơn từ dòng lệnh so với GUI, vì lý do đơn giản là chúng có thể được viết kịch bản.

Tiến sĩ Richard Hipp từng nói rằng hệ điều hành GUI lý tưởng của ông là một máy tính để bàn trống có biểu tượng để mở các cửa sổ lệnh và một biểu tượng khác để mở trình duyệt web. Tôi cảm thấy gần như cùng một cách. Nếu nó hữu ích như một chương trình dòng lệnh và không quá khó để xây dựng theo cách đó, tôi sẽ làm nó. GUI có thể là một chương trình hoàn toàn riêng biệt, có thể được xây dựng bởi người khác!

Ngày nay (ít nhất là đối với Java) có vẻ như sớm hay muộn tất cả các chương trình đều thêm dịch vụ web (SOAP hoặc Ajax hoặc cả hai) sớm hay muộn. Vì vậy, nói chung, hãy nghĩ như vậy nhưng một giao diện dịch vụ web có nhiều khả năng hơn một dòng lệnh nếu bạn muốn một phép ẩn dụ tinh thần tốt hơn ... và nhiều khả năng hơn.

Có một cách nhìn khác về mọi thứ. Thay vì cho rằng một dòng lệnh là cách duy nhất để đi, tại sao không cho rằng điều khiển lời nói có thể được sử dụng thay thế? Một mô hình hoàn toàn khác nhau được yêu cầu sau đó.

Trước khi Jobs tiếp quản Apple, các cơ chế kiểm soát giọng nói rất tinh vi đã được khám phá. Apple đã loại bỏ điều này để ủng hộ những thứ như Siri.

Thở dài.

Phổ biến và rõ ràng không phải lúc nào cũng "tốt nhất".

Đây thường là một ý tưởng tốt, vâng.

Ẩn dụ, mọi người có thể nghĩ về điều này như một hình thức thiết kế RESTful. .... không phải là một giao diện người dùng (G) điển hình có thể liên quan đến các giao dịch nhiều giai đoạn phức tạp như tạo tài khoản.

Better that one stays away from multi-stage complexity through shopping-cart-like models for transactional setup.

Tôi đã từng lập trình một phép ẩn dụ giao diện người dùng kéo trong trình duyệt. Các quy tắc tương tác rất phức tạp ở mặt sau để làm cho UX cảm thấy tự nhiên. Tôi đã giải quyết điều này bằng cách biến trang web thành API và GUI là một ứng dụng đầy đủ tạo ra các sự kiện khi hành động. Một mô-đun đã bắt những sự kiện này và, trên một bộ đếm thời gian, đã gói chúng thành 'các lệnh gọi API' (để đạt hiệu quả mạng).

Kết quả là một hệ thống cốt lõi hoàn toàn RESTful. Kết quả thứ hai là tôi có giao diện cho bên thứ 3, rằng tôi có thể hiển thị bằng cách sử dụng hồ sơ liên kết theo mô hình kinh doanh.

Một lợi thế là bạn sẽ buộc phải suy nghĩ về dòng chảy của UI từ góc độ người dùng. (Tôi đang cố gắng đạt được điều gì? Tôi cần thiết lập bối cảnh nào? Với bối cảnh đó, làm thế nào để tôi đạt được mục tiêu?)

Có một sự khác biệt lớn giữa "tạo tài khoản ngân hàng" và "viết tài liệu từ ms". Ngay cả khi bạn không xây dựng CLI, nó có thể thêm giá trị chỉ để xem xét "bối cảnh CLI" cần thiết. Mô hình không chỉ sống trong mô hình đối tượng kinh doanh!