STDIN'den bir kütüphaneden okumak için anti-pattern olarak mı kabul edilir?

İşteyken üzerinde çalıştığım büyük bir proje için bir kütüphane yazarken, bir belirtecin bir e-posta adresine gönderilmesini gerektiren ve daha sonra kullanılmak üzere kullanılabileceği koda geri gönderilen bir sorun ortaya çıktı.

Meslektaşım sadece STDIN'den (Python kullanarak code = input("Enter code: ")) okuduğunu ve daha sonra bir kullanıcının bunu ilettiğini söylüyor , ancak bana göre bu, kütüphanenin bir sunucudaki arka plan görevinde kullanılabileceği gibi kötü bir uygulama gibi görünüyor. .

Bunun bir anti-patern olarak değerlendirilip değerlendirilmediğini merak ediyordum.

Genel bir kılavuz olarak, kütüphanelerin çevre ile tamamen bağlantısı kesilmelidir. Bu, standart akışlarda, belirli dosyalarda işlem yapmamaları gerektiği veya kullanıldığı ortam veya bağlamla ilgili herhangi bir beklentileri olmadığı anlamına gelir.

Tabii ki, bu kuralın istisnaları var, ama bunun için çok iyi bir sebep olmalı. Kullanma durumunda, stdinherhangi bir sebep bulamıyorum (kütüphaneniz gerçekte std::cinC ++ 'dan olduğu gibi stdin'den okumak için rutinler sağlamazsa ). Ayrıca, G / Ç akışlarını bir parametreden kodlamalarını sağlamak yerine almak, yapmamaya değmeyecek kadar esneklik sağlar.

Bunun mutlaka bir anti-patern değil, sadece kötü tasarlanmış bir kütüphane olduğunu düşünürdüm. Girdiyi doğrudan iletilebilecek bir yöntem parametresi olarak bir dize istemek önemsiz olmalıdır.

Bu kullanıma uymuyorsa, bir yöntem parametresi bir akış olabilir, STDIN bu metoda iletilir.

Bu, bu kullanıma uymuyorsa, kütüphane yeterince esnek değildir.

Belki de kütüphanenizde, girişi her yerden okuyabilecek ve kullanıcı tarafından sağlanan bir fonksiyon için bir geri arama ayarlama yeteneğine sahip olmayı düşünün ve ardından uygun değeri kütüphanenin hangi fonksiyonunu kullanıyorsa geri getirin.

Stdin'den okursa, stdin'in program düzeyinde sahipliğini almak istediği anlamına gelir. Muhtemelen kullanımı nasıl kullandıklarına dair stdin, daha az spesifik protokolden okuyan başka bir kütüphane ile uyumlu değildir. En azından kendi kişisel sözlüğümde bu, kütüphaneyi pahalı bir tradeoff olan bir çerçeve yapacaktır .

Ancak bu durumda, kütüphane muhtemelen bir girdi dosyası tanımlayıcısı almalıdır.

@ Paul92 tarafından verilen cevap genel bir tartışmadır, ancak bunun için olası bir temiz ( çözüm ) çözüm önermek istiyorum :

Bir kitaplık, bu kodun herhangi bir çalışma zamanı ortamına uyarlanabilir olması gerekir, bu nedenle gerçekten STDINçok önemli bir veri biti isteyemezsiniz . Birincisi, kütüphanenizin kullanıcılarının bir takım sebeplerden dolayı kullanmaları mümkün olmayabilir. Bunun yerine , belirtecin nasıl alınacağını özelleştirmek için bir çeşit strateji deseni kullanmak isteyebilirsiniz .

Python'da, muhtemelen en iyi seçenek, işlev belirteç olarak belirteç alma stratejisine geçmektir. Bunun gibi bir şey:

def stdin_prompt():
    return input("Enter code: ")

def my_library_function(arg1, arg2, ... argn, token_provider = stdin_prompt):
    ...
    token = token_provider()
    ...
    return stuff

# somewhere in the user code
stuff = my_library_function(a1, a2, ... an, lambda: "123456")

Böyle düşün. İstediğiniz belirteç, kütüphane işlevinin bir argümanıdır. Belirteç değeri, arama sitesinde statik olarak bilinmediğinden, değeri argüman olarak isteyemezsiniz. Bunun yerine, arayan kişi arandığında belirteci sağlamaktan sorumlu olacak bir işlev sağlamalıdır.

Belirtecin tam mekaniğini sağlamadaki tüm sorumluluk şimdi kütüphane işlevinden dışlanmıştır. Fonksiyonun tüketicisi şimdi belirteci çalışma zamanında mevcut olan herhangi bir yöntemle elde etmekten sorumludur. STDIN'e sorabilir, ancak bir posta ağ geçidi olarak da hareket edebilir, mesajın gelen kutusuna gelmesini bekleyebilir, okuyabilir, belirteci çıkarabilir ve işlemi tamamen otomatikleştirebilirsiniz. Bir GUI iletişim kutusu veya web tabanlı bir form olabilir. Gerçekten her şey - tüm seçenekler şimdi kütüphane tüketicisinin elinde.