{"id":1430,"date":"2019-10-12T12:52:21","date_gmt":"2019-10-12T12:52:21","guid":{"rendered":"https:\/\/www.yazilimperver.com\/?p=1430"},"modified":"2019-10-12T12:52:21","modified_gmt":"2019-10-12T12:52:21","slug":"solid-4-arayuz-ayristirma-prensibi","status":"publish","type":"post","link":"https:\/\/www.yazilimperver.com\/index.php\/2019\/10\/12\/solid-4-arayuz-ayristirma-prensibi\/","title":{"rendered":"SOLID 4 \u2013 Aray\u00fcz Ayr\u0131\u015ft\u0131rma Prensibi"},"content":{"rendered":"

Evet dostlar, SOLID serimize devam ediyoruz. SOLID serisi ile ilgili di\u011fer yaz\u0131lar ve\u00a0ayn\u0131 zamanda SOLID prensipler genel anlamda neye hizmet ediyor ve genel motivasyon i\u00e7in de ilk yaz\u0131ya a\u015fa\u011f\u0131daki ba\u011flant\u0131lardan ba\u015fvurabilirsiniz:<\/p>\n

    \n
  1. SOLID 1 \u2013 Tek Sorumluluk Prensibi<\/a><\/strong><\/span><\/li>\n
  2. SOLID 2 \u2013 A\u00e7\u0131k\/Kapal\u0131 Prensibi<\/a><\/strong><\/span><\/li>\n
  3. SOLID 3 \u2013 \u201cLiskov Substitution\u201d Prensibi<\/strong><\/a><\/span><\/li>\n
  4. SOLID 4 – Aray\u00fcz Ayr\u0131\u015ft\u0131rma Prensibi<\/strong><\/span><\/a><\/li>\n<\/ol>\n

    Aray\u00fcz Ayr\u0131\u015ft\u0131rma <\/b>\u00a0Prensibi<\/b><\/strong><\/span><\/h2>\n

    \"Related<\/p>\n

    Art\u0131k son iki prensibe geldik. Bunlardan ilki aray\u00fcz ayr\u0131\u015ft\u0131rma (“interface segragation”) prensibi. Asl\u0131nda ismi size bir fikir vermi\u015ftir diye d\u00fc\u015f\u00fcn\u00fcyorum ama biz yine de bu prensibe ili\u015fkin Bob C. Martin taraf\u0131ndan yap\u0131lan tan\u0131ma bir bakal\u0131m:<\/p>\n

    The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.<\/strong><\/p><\/blockquote>\n

    Direk \u00e7evirecek olursak, ISP, herhangi bir istemci, kullanmad\u0131\u011f\u0131 bir metoda ba\u011f\u0131ml\u0131 olmamal\u0131d\u0131r<\/strong>. Bir di\u011fer ifade ile birden fazla, iyi bir \u015fekilde tan\u0131mlanm\u0131\u015f aray\u00fcz, tek ve genel bir aray\u00fczden daha iyidir. \u00d6zellikle A\u00e7\u0131k\/Kapal\u0131 Prensibinde ifade etti\u011fimiz \u00fczere, aray\u00fczler asl\u0131nda iki nesne aras\u0131nda, bir nevi kontrat\/arac\u0131 g\u00f6revi g\u00f6rmektedir. Bu sayede, kullan\u0131c\u0131 s\u0131n\u0131f, servisi ger\u00e7ekleyen s\u0131n\u0131f\u0131n bunu nas\u0131l ger\u00e7ekledi\u011fine ba\u011f\u0131ml\u0131 olmamaktad\u0131r. Sunucu, istemciye, ilgili aray\u00fczde tan\u0131mlanan davran\u0131\u015f\u0131n\u0131n sunulaca\u011f\u0131n\u0131 garanti eder.<\/p>\n

    \u015eimdi gelelim bu prensibin \u00e7\u0131k\u0131\u015f noktas\u0131na. Diyelim bir s\u0131n\u0131f tasarlad\u0131n\u0131z ve bu s\u0131n\u0131f birden fazla istemci (ya da ba\u015fla s\u0131n\u0131flar) taraf\u0131ndan kullan\u0131lmakta. Bu istemcilerin her birinin de farkl\u0131 metotlar ve servisler kulland\u0131\u011f\u0131n\u0131 d\u00fc\u015f\u00fcnelim, burada tek bir aray\u00fcz tan\u0131mlad\u0131\u011f\u0131n\u0131z durumda, aray\u00fczde sunulan metotlar kullan\u0131lmasa da, hepsini tan\u0131mlamak zorunda kal\u0131rs\u0131n\u0131z. B\u00fct\u00fcn kullan\u0131c\u0131lar da bu aray\u00fcze ba\u011f\u0131ml\u0131 kal\u0131rlar ve kullan\u0131lmayan bu aray\u00fczlere ili\u015fkin ger\u00e7ekle\u015ftirilecek her t\u00fcrl\u00fc de\u011fi\u015fikliklerden, bu istemciler de etkilenecektir. Asl\u0131nda temelde, ilgili aray\u00fczleri kullanan istemciler, b\u00fct\u00fcn sunulan aray\u00fczlere eri\u015fmeye de ihtiya\u00e7lar\u0131 yok. Bunun yerine, Bob amcan\u0131n da ifade etti\u011fi \u00fczere, daha k\u00fc\u00e7\u00fck ve sadece ilgili istemcilerin ihtiya\u00e7 duyaca\u011f\u0131 metotlar\u0131 i\u00e7eren, rol aray\u00fczler tan\u0131mlanmal\u0131d\u0131r.<\/p>\n

    Tabi burada akl\u0131m\u0131z hemen, karde\u015fim her bir istemci i\u00e7in ayr\u0131 ayr\u0131 aray\u00fcz m\u00fc tan\u0131mlayay\u0131m, bu sefer de aray\u00fcz \u00e7\u00f6pl\u00fc\u011f\u00fcne d\u00f6nmesin? Kesinlikle hakl\u0131s\u0131n\u0131z, burada \u00f6nemli olan, istemcileri ve ihtiya\u00e7 duyduklar\u0131 belirleyerek konsolide etmek ve benzer istemciler, ilgili aray\u00fczler sunmakt\u0131r.\u00a0Tahmin edebilece\u011finiz \u00fczere, burada s\u0131n\u0131flara ili\u015fkin sunulacak olan aray\u00fczleri do\u011fru belirlemek olduk\u00e7a \u00f6nemli. Lakin, a\u015fa\u011f\u0131da verdi\u011fim bir \u00e7ok kaynakta da ifade edildi\u011fi \u00fczere bunu yapabilmek i\u00e7in biraz alan bilgisine de ihtiya\u00e7 da var.\u00a0 Bunu yapmak i\u00e7in, olas\u0131 alandaki kullan\u0131m senaryolar\u0131 incelenebilir, olas\u0131 etkile\u015fimler ve aray\u00fczler belirlenebilir. Aray\u00fczler belirlendikten sonra da muhakkak kendimize “Bu aray\u00fczdeki b\u00fct\u00fcn metotlara ihtiyac\u0131m var m\u0131, kullan\u0131yor muyum? E\u011fer de\u011filse, bunlar\u0131 nas\u0131l daha k\u00fc\u00e7\u00fck aray\u00fczlere ay\u0131rabilirim?” sorular\u0131n\u0131 sormal\u0131y\u0131z.<\/p>\n

    Evet s\u00f6z\u00fc daha fazla uzatmadan hemen bir \u00f6rnek \u00fczerinden (\u00d6rne\u011fin kayna\u011f\u0131 da yine Robert C. Martin’in yaz\u0131s\u0131) bu prensibi biraz daha derinlemesine inceleyelim. A\u015fa\u011f\u0131daki fig\u00fcrde, \u00fc\u00e7 kullan\u0131c\u0131s\u0131 olan bir s\u0131n\u0131f g\u00f6sterilmekte. Mevcut s\u0131n\u0131f, bu \u00fc\u00e7 istemciye de servis sunuyor, yani ilgili metotlar tan\u0131mlanm\u0131\u015f. Service s\u0131n\u0131f\u0131nda ger\u00e7ekle\u015ftirilecek k\u00fc\u00e7\u00fck bir de\u011fi\u015fiklik durumunda her \u00fc\u00e7 istemcinin de bir daha derlenerek, kullan\u0131ma sunulmas\u0131 gerekmekte.<\/p>\n

    \"\"<\/p>\n

    Peki bu s\u0131n\u0131f\u0131 nas\u0131l daha iyi hale getirebiliriz? Her bir istemci i\u00e7in gerekli aray\u00fczleri tan\u0131mlar ve istemcileri sadece bunlara ba\u011f\u0131ml\u0131 hale getirebiliriz. \u015e\u00f6yle ki:<\/p>\n

    \"\"<\/p>\n

    G\u00f6r\u00fclece\u011fi \u00fczere, art\u0131k her bir istemci sadece ilgilendi\u011fi aray\u00fcz\u00fc kullanmakta ve Service<\/em> s\u0131n\u0131f\u0131 da b\u00fct\u00fcn bu aray\u00fczleri ger\u00e7eklemekte. Diyelim Service A<\/em> da bir de\u011fi\u015fiklik oldu bu durumda sadece Client A<\/em>‘n\u0131n g\u00fcncellenmesi (derlenerek, kullan\u0131ma sunulmas\u0131) yeterli olacakt\u0131r ve di\u011ferleri bu de\u011fi\u015fiklikten etkilenmeyecekler. Peki, farkl\u0131 aray\u00fczlerin ortak metotlar\u0131 kulland\u0131\u011f\u0131 durumda ne yapaca\u011f\u0131z? Bunlar i\u00e7in ayr\u0131 bir ortak aray\u00fcz m\u00fc tan\u0131mlayaca\u011f\u0131z? Bu durumda, bu metotlar\u0131 her bir aray\u00fcz i\u00e7in \u00e7oklamakta bir s\u0131k\u0131nt\u0131 yok, zaten Service s\u0131n\u0131f\u0131 bunu ger\u00e7ekleyecek ve ayn\u0131 servis her bir aray\u00fcz arac\u0131l\u0131\u011f\u0131 ile sunulacakt\u0131r. E\u011fer, aray\u00fczlere ili\u015fkin \u00e7ok ciddi g\u00fcncellemelerin yap\u0131lmas\u0131 veya eklemelerin yap\u0131lmas\u0131 durumunda, mevcut aray\u00fczleri de\u011fi\u015ftirmektense, yeni aray\u00fczlerin tan\u0131mlanmas\u0131 tercih edilebilir.<\/p>\n

    Sonu\u00e7 olarak burada tan\u0131mlayaca\u011f\u0131m\u0131z aray\u00fczlerin olabildi\u011fince k\u00fc\u00e7\u00fck, kohezif ve sa\u011flam olmas\u0131na dikkat etmeliyiz. E\u011fer bir aray\u00fczde yap\u0131lan de\u011fi\u015fiklik, bunun ile hi\u00e7 ilgisi olmayan ba\u015fka bir aray\u00fcz\u00fc etkiliyorsa, bir yerlerde yanl\u0131\u015f yapt\u0131\u011f\u0131m\u0131z anlam\u0131na gelebilir. Bu prensibe uyulmamas\u0131 sonucu, s\u0131n\u0131flar aras\u0131nda gereksiz, ba\u011f\u0131ml\u0131l\u0131klara sebebiyet vermi\u015f olaca\u011f\u0131z ve bu da uzun vadede bizlere bak\u0131m ve idame maliyeti olarak geri d\u00f6necektir.<\/p>\n

    Bu arada, literat\u00fcrde bu \u015fekilde bir \u00e7ok servisin tek bir aray\u00fczden sunulmas\u0131 “fat interfaces” ya da “interface pollution” gibi ibarelerle de ifade edilmekte. Bir di\u011fer ifade ile, \u00e7ok fazla davran\u0131\u015f\/metodun tek bir aray\u00fcz arac\u0131l\u0131\u011f\u0131 ile sunulmas\u0131. \u0130simleri de zaten pek \u00e7ekici de\u011fil, \u00f6yle de\u011fil mi? Bu prensibin, bu anlamda detayl\u0131 bir \u015fekilde incelenmesini ve \u00f6rneklendirilmesini \u015fu yaz\u0131da<\/a><\/strong><\/span> g\u00f6rebilirsiniz.<\/p>\n

    Bunun ile birlikte i\u015fin kodlama k\u0131sm\u0131na bakt\u0131\u011f\u0131n\u0131zda, bir \u00e7ok dil bu anlamda mekanizmalar sunuyor. \u00d6rne\u011fin, C++ farkl\u0131 soyut aray\u00fcz s\u0131n\u0131flar\u0131ndan s\u0131n\u0131flar\u0131n\u0131z\u0131 t\u00fcretmenize, \u00e7oklu miras mekanizmas\u0131 ile, olanak sa\u011fl\u0131yor. Tabi bu \u00e7oklu miras konusunda her zaman dikkatli olmakta fayda var. Benzer \u015fekilde C# ve Java gibi programlama dillerinde de, s\u0131n\u0131flar birden fazla aray\u00fczden t\u00fcretilebilmektedir.<\/p>\n

    Son olarak, bu prensip ile SRP, yani tek sorumluluk prensibi asl\u0131nda \u00e7at\u0131\u015fm\u0131yor mu diye akl\u0131n\u0131za bir soru gelebilir. Sonu\u00e7ta, SRP’de g\u00f6rd\u00fc\u011f\u00fcm\u00fcz \u00fczere her bir s\u0131n\u0131f\u0131n tek bir sorumlulu\u011fu olmas\u0131 gerekti\u011fini ifade etmi\u015ftik, burada ise tek bir aray\u00fcz yerine birden fazla aray\u00fcz kullanmaktan bahsettik. Bu birden fazla aray\u00fcz, birden fazla sorumluluk anlam\u0131na gelmiyor mu? Asl\u0131nda gelmiyor, SRP yaz\u0131m\u0131zdan bir \u00f6rnek vermeye \u00e7al\u0131\u015fay\u0131m. Orada \u00f6rne\u011fin hem haberle\u015fme sorumlulu\u011fu hem de raporlama sorumlulu\u011fu tek bir s\u0131n\u0131fa y\u00fcklenmi\u015fti ve biz de bunlar\u0131 ay\u0131rm\u0131\u015ft\u0131k. Ama daha da ileri gidip, haberle\u015fme kabiliyetini, veri g\u00f6nderme ve alma olarak ay\u0131rmad\u0131k. \u00c7\u00fcnk\u00fc bu iki alt kabiliyet asl\u0131nda birbirleri ile ilintili ve bunlar\u0131 ay\u0131rmak pratik de\u011fil. Bunu yerine bunlar\u0131 ayn\u0131 s\u0131n\u0131f\u0131n iki farkl\u0131 aray\u00fcz\u00fc ile sunabiliriz. A\u015fa\u011f\u0131da bu do\u011frultuda g\u00fcncellenmi\u015f kodu g\u00f6rebilirsiniz.\u00a0Bu anlamda hem SRP hem de ISP’yi sa\u011flam\u0131\u015f oluyoruz.<\/p>\n

    class ICommunicationSenderItem\r\n{\r\npublic:\r\n\tvirtual bool initialize() = 0;\r\n\tvirtual bool sendMessage(const char* rawData) = 0;\r\n};\r\n\r\nclass ICommunicationReceiverItem\r\n{\r\npublic:\r\n\tvirtual bool initialize() = 0;\r\n\tvirtual bool receiveMessage() = 0;\r\n};\r\n \r\n\/\/ TCP uzerinden hem dinleme hem de gonderme yapan istemci sinifi\r\nclass TCPSocketCommunication\r\n\t: public ICommunicationSenderItem,\r\n\t  public ICommunicationReceiverItem,\r\n{\r\npublic:\r\n\tvirtual bool initialize()\r\n\t{\r\n\t\t\/\/ Soket haberle\u015fmesine ili\u015fkin ilklendirmeler\r\n\t}\r\n\tvirtual bool sendMessage(const char* rawData)  override\r\n\t{\r\n\t\t\/\/ Soket uzerinden mesaj gonderme kodu\r\n\t}\r\n\tvirtual bool receiveMessage()\r\n\t{\r\n\t\t\/\/ Soket uzerinden mesaj gonderme alma kodu\t\r\n\t} \r\n\t\/\/ Sokete iliskin ozellesmis metotlar\r\n\tvoid setSocketParameters(const string ipAddress, int portNo)\r\n\t{\r\n\t\t\/\/ Soket parametreleri\r\n\t}\r\n};\r\n \r\n\/\/ Seri kanal uzerinden sadece dinleme yapmak isteyen kullanici sinifi\r\nclass SerialCommunicationListener\r\n\t: public ICommunicationReceiverItem\r\n{\r\npublic:\r\n\tvirtual bool initialize()\r\n\t{\r\n\t\t\/\/ Seri kanal uzerinden haberle\u015fmeye ili\u015fkin ilklendirmeler\r\n\t}\r\n \r\n\tvirtual bool receiveMessage()  override\r\n\t{\t\t\r\n\t\t\/\/ Seri kanal uzerinden dinleme kod\r\n\t}\r\n \r\n\t\/\/ Seri kanala iliskin ozellesmis metotlar\r\n\tvoid setSerialPortParameters(eBaudRate baudRate, eDataBit dataBits, eParity parity,)\r\n\t{\r\n\t\t\/\/ Seri kanal parametreleri\r\n\t}\r\n}<\/pre>\n
    SRP olaya, biraz daha s\u0131n\u0131f\u0131n tasar\u0131m\u0131 noktas\u0131ndan yakla\u015f\u0131rken, ISP daha \u00e7ok, istemci g\u00f6z\u00fcnden bak\u0131yor. Bu iki prensibe ili\u015fkin di\u011fer kar\u015f\u0131la\u015ft\u0131rma sonu\u00e7lar\u0131na kaynaklar k\u0131sm\u0131ndan ula\u015fabilirsiniz.<\/p>\n
    Sonu\u00e7 olarak, bu prensip bize, b\u00fcy\u00fck ve genel bir aray\u00fczdense, istemcilere \u00f6zel birden fazla, k\u00fc\u00e7\u00fck ve \u00f6z aray\u00fczler sunmam\u0131z\u0131 \u00f6nermekte. Ayr\u0131ca, soyutlamalar\u0131m\u0131za do\u011fru bir \u015fekilde yap\u0131p\/yapmad\u0131\u011f\u0131m\u0131za dair de bir fikir vermekte ve mevcut yaz\u0131l\u0131mlar\u0131n tasar\u0131mlar\u0131 i\u00e7in de, bu anlamda \u00f6nemli bir g\u00f6stergedir. Bu \u015fekilde geli\u015ftirmi\u015f oldu\u011fumuz yaz\u0131l\u0131mlar sayesinde, ger\u00e7ekle\u015febilecek (ki her yaz\u0131l\u0131m i\u00e7in bu ka\u00e7\u0131n\u0131lmazd\u0131r \ud83d\ude42 de\u011fi\u015fiklikler, h\u0131zl\u0131 ve daha kolay bir \u015fekilde uygulayabileceksiniz.<\/p>\n
    Bir sonraki ve son SOLID prensibinde g\u00f6r\u00fc\u015fmek dile\u011fiyle…<\/p>\n
    Kaynaklar:<\/span><\/h2>\n