Bir arabirimin (OOP) anlamsal sözleşmesi bir işlev imzasından (FP) daha bilgilendirici midir?

Bazıları tarafından, eğer SOLID ilkelerini aşırı uçlarına götürürseniz, fonksiyonel programlamaya son verdiğiniz söylenir . Bu makaleye katılıyorum, ancak arayüz / nesneden işlev / kapanışa geçişte bazı anlambilimin kaybolduğunu düşünüyorum ve İşlevsel Programlamanın kaybı nasıl azaltabileceğini bilmek istiyorum.

Makaleden:

Ayrıca, Arabirim Ayrışma İlkesini (ISS) titizlikle uygularsanız, Başlık Arabirimleri yerine Rol Arabirimleri'ni tercih etmeniz gerektiğini anlayacaksınız.

Tasarımınızı daha küçük ve daha küçük arayüzlere doğru sürmeye devam ederseniz, en sonunda nihai Rol Arayüzüne ulaşırsınız: tek bir yöntemle bir arayüz. Bu bana çok şey oluyor. İşte bir örnek:

public interface IMessageQuery
{
    string Read(int id);
}

Bir bağımlılık alırsamIMessageQuery , örtük sözleşmenin bir parçası, çağrı Read(id), verilen kimliğe sahip bir mesaj arayacak ve döndürecektir.

Bunu, eşdeğer işlevsel imzasına bağımlı olmakla karşılaştırın int -> string. Herhangi bir ek ipucu olmadan, bu işlev basit olabilir ToString(). Eğer IMessageQuery.Read(int id)bir ile uyguladıysan , ToString()seni kasten yıkıcı olmakla suçlayabilirim!

Peki, işlevsel programcılar iyi adlandırılmış bir arabirimin anlambilimini korumak için ne yapabilir? Örneğin, tek üyeli bir kayıt türü oluşturmak geleneksel midir?

type MessageQuery = {
    Read: int -> string
}

Telastyn'in dediği gibi, işlevlerin statik tanımlarını karşılaştırmak:

public string Read(int id) { /*...*/ }

için

let read (id:int) = //...

OOP'tan FP'ye giden hiçbir şeyi gerçekten kaybetmediniz.

Bununla birlikte, bu hikayenin sadece bir parçasıdır, çünkü işlevler ve arayüzler sadece statik tanımlarında belirtilmez. Onlar da etrafta dolaşıyorlar . Diyelim ki MessageQuerybaşka bir kod parçası tarafından okundu, a MessageProcessor. Sonra elimizde:

public void ProcessMessage(int messageId, IMessageQuery messageReader) { /*...*/ }

Şimdi yöntem adını veya parametresini doğrudan göremiyoruz , ancak oraya IDE'mizden kolayca ulaşabiliriz. Daha genel olarak, int'den dizeye bir işlev içeren bir yöntemle yalnızca herhangi bir arabirimden geçmemiz, bu parametre adı meta verilerini bu işlevle ilişkili tuttuğumuz anlamına gelir .IMessageQuery.Readint idIMessageQueryid

Öte yandan, fonksiyonel versiyonumuz için:

let read (id:int) (messageReader : int -> string) = // ...

Peki ne sakladık ve kaybettik? Yine de, messageReadermuhtemelen tür adını (buna eşdeğer IMessageQuery) gereksiz kılan parametre adına sahibiz . Ama şimdi idfonksiyonumuzdaki parametre adını kaybettik .

Bunun etrafında iki ana yol var:

• İlk olarak, bu imzayı okuduktan sonra, neler olup bittiğini oldukça iyi tahmin edebilirsiniz. İşlevleri kısa, basit ve uyumlu tutarak ve iyi adlandırma kullanarak, bu bilgileri sezmeyi veya bulmayı çok daha kolay hale getirirsiniz. Asıl fonksiyonun kendisini okuduktan sonra, daha da basit olurdu.

• İkincisi, ilkelleri sarmak için küçük tipler oluşturmak için birçok işlevsel dilde deyimsel tasarım olarak kabul edilir . Bu durumda, tam tersi gerçekleşir - bir tür adını bir parametre adı ( IMessageQueryyerine messageReader) ile değiştirmek yerine, bir parametre adını bir tür adıyla değiştirebiliriz. Örneğin, intşu şekilde adlandırılabilir Id:

  type Id = Id of int
  

  Şimdi readimzamız:

  let read (id:int) (messageReader : Id -> string) = // ...
  

  Bu da daha önce sahip olduğumuz kadar bilgilendirici.

  Bir yan not olarak, bu bize OOP'de sahip olduğumuz bazı derleyici korumasını da sağlar. OOP sürümü sağlanmalıdır Oysa biz özellikle aldı IMessageQuerysadece herhangi bir eski yerine int -> stringişlevi, burada biz bir alıyorsun o benzer (ama farklı) koruması Id -> stringsadece herhangi bir eski yerine int -> string.

% 100 güvenle, bu tekniklerin her zaman bir arayüzde tam bilgiye sahip olmak kadar iyi ve bilgilendirici olacağını söylemek konusunda isteksiz olurum, ancak yukarıdaki örneklerden, çoğu zaman, muhtemelen bir iş kadar iyi yapabilir.

FP yaparken daha spesifik semantik tipler kullanmaya eğilimliyim.

Örneğin, benim için yönteminiz şöyle bir şey olurdu:

read: MessageId -> Message

Bu, OO (/ java) tarzı ThingDoer.doThing()stilden çok daha fazla iletişim kurar

Peki, işlevsel programcılar iyi adlandırılmış bir arabirimin anlambilimini korumak için ne yapabilir?

İyi adlandırılmış işlevler kullanın.

IMessageQuery::Read: int -> stringbasitçe ReadMessageQuery: int -> stringya da benzer bir şey olur .

Dikkat edilmesi gereken en önemli şey, isimlerin sadece kelimenin en gevşek anlamında sözleşmeler olmasıdır. Yalnızca siz ve başka bir programcı adından aynı sonuçları çıkarırsanız ve onlara itaat ederseniz çalışırlar. Bu nedenle, bu zımni davranışı ileten herhangi bir adı kullanabilirsiniz . OO ve fonksiyonel programlama adları biraz farklı yerlerde ve biraz farklı şekillerde bulunur, ancak işlevleri aynıdır.

Bir arabirimin (OOP) anlamsal sözleşmesi bir işlev imzasından (FP) daha bilgilendirici midir?

Bu örnekte değil. Yukarıda açıkladığım gibi, tek bir işleve sahip tek bir sınıf / arabirim, benzer şekilde iyi adlandırılmış bağımsız bir işleve göre anlamlı olarak daha bilgilendirici değildir.

Bir sınıfta birden fazla işlev / alan / özellik edindikten sonra, bunlar hakkında daha fazla bilgi çıkarabilirsiniz, çünkü ilişkilerini görebilirsiniz. Aynı / benzer parametreleri alan bağımsız işlevlerden veya ad alanı veya modül tarafından düzenlenen bağımsız işlevlerden daha bilgilendirici olup olmadığı tartışılabilir.

Şahsen, OO'nun daha karmaşık örneklerde bile önemli ölçüde daha bilgilendirici olduğunu düşünmüyorum.

Tek bir işlevin 'anlamsal bir sözleşmeye' sahip olamayacağını kabul etmiyorum. Şu yasaları göz önünde bulundurun foldr:

foldr f z nil = z
foldr f z (singleton x) = f x z
foldr f z (xn <> ys) = foldr f (foldr f z ys) xn

Hangi anlamda anlamsal değil, sözleşme değil? 'Katlayıcı' için bir tür tanımlamanız gerekmez, özellikle foldrbu yasalar tarafından benzersiz bir şekilde belirlenir. Ne yapacağını biliyorsun.

Bir tür işlev almak istiyorsanız, aynı şeyi yapabilirsiniz:

-- The first argument `f` must satisfy for all x, y, z
-- > f x x = true
-- > f x y = true and f y x = true implies x = y
-- > f x y = true and f y z = true implies f x z = true
sort :: forall 'a. (a -> a -> bool.t) -> list.t a -> list.t a;

Bu sözleşmeyi yalnızca aynı sözleşmeye birden çok kez ihtiyacınız varsa adlandırmanız ve yakalamanız gerekir:

-- Type of functions `f` satisfying, for all x, y, z
-- > f x x = true
-- > f x y = true and f y x = true implies x = y
-- > f x y = true and f y z = true implies f x z = true
type comparison.t 'a = a -> a -> bool.t;

Tür denetleyicisi, bir türe atadığınız anlambilimi zorlamayacaktır; bu nedenle, her sözleşme için yeni bir tür oluşturmak yalnızca kaynaktır.

Hemen hemen tüm statik olarak yazılan fonksiyonel diller, temel türleri semantik niyetinizi açıkça belirtmenizi gerektiren bir şekilde diğer adlara takma yoluna sahiptir. Diğer cevaplardan bazıları örnek vermiştir. Pratikte, deneyimli işlevsel programcıların bu sarıcı tiplerini kullanmak için çok iyi nedenlere ihtiyaçları vardır, çünkü bunlar sıkıştırılabilirliğe ve tekrar kullanılabilirliğe zarar verirler.

Örneğin, bir müşterinin bir liste tarafından desteklenen bir mesaj sorgusunun uygulanmasını istediğini varsayalım. Haskell'de uygulama şu kadar basit olabilir:

messages = ["Message 0", "Message 1", "Message 2"]
messageQuery = (messages !!)

newtype Message = Message StringBunu kullanmak çok daha az açıktır ve bu uygulamayı aşağıdaki gibi bir şey olarak bırakır:

messages = map Message ["Message 0", "Message 1", "Message 2"]
messageQuery (Id index) = messages !! index

Bu büyük bir anlaşma gibi görünmeyebilir, ama ya ileri o tür dönüştürmesi geri yapmak zorunda ve her yerde , ya da yukarıda herşey Kodunuzdaki bir sınır tabakası kurmak Int -> Stringo zaman dönüştürmek Id -> Messageaşağıda tabakasına geçmesine. Diyelim ki uluslararasılaştırma eklemek veya tüm büyük harflerle biçimlendirmek ya da günlük bağlamı ya da başka bir şey eklemek istedim. Bu operasyonların tümü bir ile bestelemek çok basit Int -> Stringve bir ile can sıkıcı Id -> Message. Artan tür kısıtlamalarının istendiği durumlar asla değildir, ancak rahatsızlık değiş tokuşa değer olsa iyi olur.

Bir sarmalayıcı yerine (bunun yerine Haskell'de ) bir tür eş anlamlı kullanabilirsiniz , bu çok daha yaygındır ve her yerde dönüşüm gerektirmez, ancak OOP sürümünüz gibi statik tür garantileri sağlamaz, sadece biraz kapsülleme. Tip sarmalayıcılar çoğunlukla müşterinin değeri değiştirmesi beklenmeyen yerlerde kullanılır, sadece saklayın ve geri verin. Örneğin, bir dosya tanıtıcısı.typenewtype

Hiçbir şey bir istemcinin "yıkıcı" olmasını engelleyemez. Her müşteri için sadece atlamak için çemberler oluşturuyorsun. Ortak bir birim testi için basit bir alay genellikle üretimde mantıklı olmayan garip davranışlar gerektirir . Arayüzleriniz mümkün olduğu takdirde umursamayacakları şekilde yazılmalıdır.