Nesne yönelimi ve algoritmalar arasındaki ilişki


9

Bazı algoritmalar ders kitaplarını okurken, bazı problemler (sıralama, en kısa yol) veya bazı genel yöntemler (özyinelemeli algoritmalar, böl ve fethet, dinamik programlama ...) için akıllı prosedürlerle doludur. Orada nesne yönelimli programlamanın birkaç izini buldum; (Neden daha prosedür odaklılar?).

Sonra düşünüyordum:

  • Algoritmalar ve OOP arasındaki ilişki nedir? İki bağımsız konu mu?
  • Sadece OOP tarafından sunulabilecek ve çözülebilecek bazı sorunlar var mı?
  • OOP algoritmalara nasıl yardımcı olabilir? Ya da hangi yönde etkileyebilir?

4
Yinelenen değil, ilgili programcılar.stackexchange.com/
Doc Brown

@DocBrown Teşekkür ederim, bu çok yardımcı oldu, ancak burada OO etrafında kalıtım, polimorfizm gibi bazı kavramları düşünebiliriz
Ahmad

1
"Neden algoritmalar ders kitabı daha prosedüre yönelik?" Java da prosedüre yöneliktir. Java, nesne yönelimli bir prosedür dilidir.
Pieter B


1
@gnat Sorumu değiştirdim, bu açıklamanın gerekli olup olmadığını bilmiyorum. Ancak Doc Brown tarafından yöneltilen sorunun endişelerimle ilgili daha fazla cevabı olduğunu itiraf ediyorum.
Ahmad

Yanıtlar:


10

İlk olarak, OOP ile ne demek istediğimizi tanımlayalım. OOP ile öncelikle demek istediğim:

  • Sınıfta ayrıntıların kapsüllenmesi ve gizlenmesi.
  • Kalıtım ve sanal yöntemlerle davranış polimorfizmi.

Şimdi, sorunuzu cevaplamak için:

Algoritmalar ve OOP arasındaki ilişki nedir? İki bağımsız konu mu?

Evet.

Sadece OOP tarafından sunulabilecek ve çözülebilecek bazı sorunlar var mı?

Hayır. OOP birincil, programcı için kod hakkında kolaylık ve muhakeme yeteneği sunar. Etkileyici gücünüzü artırmaz.

OOP algoritmalara nasıl yardımcı olabilir? Ya da hangi yönde etkileyebilir?

Yukarıda söylediğim gibi. OOP tanımladığım her iki nokta da burada geçerlidir. Algoritmaların detaylarını ve veri yapılarını gizleyebilmek her şey için mantığa yardımcı olabilir. Birçok algoritma, kullanıcının bu algoritmayı karıştırmasını istemediğiniz ayrıntıları içerir. Bu ayrıntıları gizlemek çok yardımcı olur.

Polimorfik davranışa sahip olmak da büyüktür. Listkoleksiyonun herhangi bir yerine öğe ekleyebilme / kaldırabilme / silme olarak tanımlanır. Ancak, yeniden boyutlandırılabilir dizi, çift bağlantılı veya tek bağlantılı vb.

Neden algoritmalar ders kitabı daha prosedüre yönelik?

Dediğim gibi, OOP bir algoritma uygulamak için gerekli değildir. Ayrıca, birçok algoritma eskidir ve OOP hala yaygın olmadığında oluşturulur. Yani tarihsel bir şey de olabilir.


1
Metinlerin yaşına rağmen, muhtemelen modern olduğu için bir algoritmanın suyunu OOP ile çamurlamak istemezsiniz.
Gusdor

15

Algoritmalar ve OOP , sadece ortak olan, CS -term oldukları iki farklı terimdir. Basitçe - Bir algoritma bir yemek tarifi gibidir: x yapmak için aşağıdaki bileşenlere ihtiyacınız var ve adım 1,2,3,4,5,6 ... yapmanız gerekir.

Bununla birlikte, algoritmaların prosedürel bir şekilde tanımlanması doğal bir uyum gibi görünmektedir . Usul araçlar hiçbir şey dışında: İlk do x ve sonra bunu y .

Yaygın bir sorun şudur: »Bir x kümesi nasıl sıralanır ?«. Kolay anlaşılır bir çözüm bubble-sort:

  1. İlk öğeye ulaşmadığınız sürece ve yineleme sırasında son öğeden küme üzerinde yineleme yapın
  2. Başlangıçtan ilk yinelemenin şu anki öğesine ikinci bir yineleme başlatın ve
  3. (2) 'nin mevcut elemanını halefi ile karşılaştırın
  4. Daha büyükse, takas konumları

bubblesort-Algoritmanın algoritmik / sözlü tanımı budur.

İşte bir yordamsal / sözde kod uygulaması

bubbleSort(Array A)
  for (n=A.size; n>1; n=n-1){
    for (i=0; i<n-1; i=i+1){
      if (A[i] > A[i+1]){
        A.swap(i, i+1)
    } 
  } 
}

Kolaydı.

Bu OOP ile nasıl ilişkilidir ? Nesnelerin koleksiyonlarını (bir nesnenin kendisi) tedavi etmek için bu algoritmayı kullanabilirsiniz :

Javascript'te örnek ( temiz OO-Lingo olmasa da , kaynamaya yakın ve anlaşılması kolay)

objects =[{"name":"Peter"}, {"name":"Paul"}, {"name":"Mary"}]

compareObjects=function(x,y){ return x.name>y.name };

sorted = objects.sort(compareObjects)

console.log(sorted)

Biz a) bir koleksiyon objects, b) bu koleksiyona bir yöntem ortak sort/ içeriyor uzakta sıralama algoritması ve soyutlar c) bizim nesneleri Peter , Paul ve Mary . Sıralama için Şartname burada bulunur .

Algoritmalar ve OOP arasındaki ilişki nedir? İki bağımsız konu mu?

Söylenenlere göre, açık olmalı, cevap şu olmalı: evet, bağımsızlar.

OOP algoritmalara nasıl yardımcı olabilir? Ya da hangi yönde etkileyebilir?

OOP sadece bir programlama stilidir. Herhangi bir şekilde yardımcı olamaz . Aksi takdirde, nesnelere bir şeyler yapmak için OO dilinde bir algoritma uygulanabilir (gösterildiği gibi)

Sadece OOP tarafından sunulabilecek ve çözülebilecek bazı sorunlar var mı?

Birini düşünemiyorum (ama bu imkansız olduğu anlamına gelmez). Ancak başka bir şekilde bakarsanız: OOP yararlıdır, bazı problemleri modellemek ve uygun bir algoritma ile ith'i çözmek istiyorsanız. Eğer bir kayıt olması Say friendsolarak modellik olabilir size objectsolan propertiesve bir isterseniz listait friends sıralanmış herhangi bir şekilde, tam olarak bunu yapmak için yukarıda verilen örnek-kodu kullanabilirsiniz.

Neden algoritmalar ders kitabı daha prosedüre yönelik?

Dediği gibi: o daha doğal , çünkü usul olup karakter algoritmaları.


7
Bu cevap algoritmaların doğal olarak prosedürel olduğunu varsayar. Kesinlikle bazıları öyle, ama fonksiyonel algoritmalar diye bir şey var. Algoritma kitaplarının yordamsal olmasının nedeni muhtemelen performansa odaklanmış olmaları ile daha fazla ilgilidir ve bu nedenle soyutlamaları uygulama konusunda endişelenmek okuyucuya bağlıdır ve zorunlu diller işlevsel dillerden daha popülerdir.
Doval

Bence bu pek doğru değil. Söz ederken fonksiyonel programlama dilleri, sen neden bahsediyorsun uygulanması değil algoritmanın kendisi. Örneğin, Haskell'in quicksort wiki.haskell.org/Introduction#Quicksort_in_Haskell İkimiz de bunun, quicksort-algoritmahm için işlevsel bir uygulama olduğu konusunda hemfikiriz. Eğer Ama eğer açıklamak , ne bir yer son çare olarak zorunda yapılır prodecural modda açıklamasının. Ve bu açıklamadan, prosedürel bir uygulama uygulayabilirsiniz.
Thomas Junk

1
@ThomasJunk Sen yok fonksiyonel uygulama şeyler nelerdir diyor çünkü açıklamanın usul moduna geri düşmek zorunda olan , adımların bir dizi değil. Saf ve tembel bir hesaplama için nasıl sıralı bir açıklama yapacaksınız? İfadenin ne kadarının değerlendirileceğini veya alt ifadelerinin hangi sırayla hesaplanacağını önceden bilmiyorsunuz.
Doval

2
Ne yazık ki CS derecem yok, bu yüzden aşağıdakileri kanıtlamak için geniş bir beceri setinden yoksun: Ama bence, her algoritma şu ya da bu şekilde tanımlanabilir.Yani gerçek bir saf fonksiyonel algoritma yoktur. Sonuçta, turne eksiksizliğinin anlamı nedir?
Thomas Junk

2
@ Turing'in kendisi lambda kalkülüsünün ve Turing makinelerinin eşdeğer olduğunu kanıtladığından iyi sonuçlanır, o zaman işlevsel bir şekilde ifade edebileceğiniz her şeyi zorunluluk olarak yapabilirsiniz. Ayrıca tembel hesaplamayı zorunlu biçime dönüştürmek önemsizdir - Haskell'in derleyicisi her zaman yapar ... Sonunda sadece bir tercih meselesi. Bazen fonksiyonel daha uygun ve bazen de zorunludur ve diğer zamanlarda mantıklı en iyisidir ...
AK_

5

bir sorunun var.

İşletme etki alanı modeli sorununuzu açıklar ve gideceğiniz sorun etki alanındaki kavramlar ilgilenir.

Algoritmalar , sorunlarınızı kavramsal olarak nasıl çözeceğinizi açıklar; uygulamanız nasıl görünecek; ve "Bilgisayar Bilimi" terimlerine çevirdikten sonra sorununuzu nasıl çözersiniz?

Programlama paradigması, ister OOP, ister Fonksiyonel, Mantıksal, Prosedürel, hatta Yapılandırılmamış olsun, çözümünüzü nasıl yapılandıracağınızı, hangi formu alacağınızı, hangi "Yazılım Mühendisliği" kavramlarını istihdam edeceğinizi ve hangi " Programlama Dil Kuramı "kavramlarını kullanacağınız.

Daha basit bir ifadeyle, algoritmalar genel olarak soruna çözümünüzü tanımlar ("Ben de bunu yapacağım"). Programlama paradigması asıl uygulamanızla ilgilenir ("Ben bunu nasıl yapacağım").


Muhtemel kusurlu bir şekilde, bildirici dillerin "nasıl" adımını azaltmayı veya ortadan kaldırmayı amaçladığını unutmayın. Amaçları sizin için basitçe "istediğim budur" demektir (örneğin, üst düzey denklemler yazarak). Tipik bir SQL sorgusu düşünün: çok azı "algoritmik"; veritabanına ne istediğinizi söylemeniz yeterlidir ve isteğinizi nasıl ele alacağına bağlıdır (elbette belirli sınırlamalar dahilinde).
Andres F.

4

Algoritmalar = " Nasıl " öyküsünü anlatın (yani, istenen sonuçları üretmek için veri yapılarını kullanarak giriş verilerinin nasıl işleneceği)

OOP = OO dilleri tarafından size bellek güvenliği ve soyutlama sağlayan programlar (= algoritmalar + veri yapıları) yazmak için kolaylaştırılan bir " Metodoloji "

OOP sadece algoritma uygulama paradigmasıdır.

İyi benzetme : filmler

Bir dublör kullanarak ya da değil sahneleri kaydedebilirsiniz. Senaryo (algoritma) değişmez. İnsanlar nihai sonuçta herhangi bir fark görmemelidir.

DÜZENLEME: kaliteli bir MOOC deneyebilirsiniz: https://www.coursera.org/course/algs4partI tartışılan konuları (özellikle OOP yaklaşımı) harmanlayan ve burada sorduğunuz şeyin özünü veren.


Film benzetmenizden gerçekten keyif aldım. Gelecekte ödünç alacağım.
Marc LaFleur

2

Alexander Stepanov, C ++ için temel algoritma kütüphanesi olan C ++ Standart Şablon Kütüphanesi'nin (STL) orijinal yaratıcısıdır. C ++, "Nesneye Dayalı" özellikler içeren çok paradigma bir dildir, ancak Alexander Stepanov'un Nesne Yönelimi hakkında şunları söylemesi gerekir:

http://www.stlport.org/resources/StepanovUSA.html

STL nesne yönelimli değildir. Nesne yöneliminin Yapay Zeka kadar neredeyse bir aldatmaca olduğunu düşünüyorum. Henüz bu OO insanlarından gelen ilginç bir kod parçası görmedim.

OOP'yi teknik olarak sağlam buluyorum. Tek bir tipte değişen arayüzler açısından dünyayı parçalamaya çalışır. Gerçek problemlerle başa çıkmak için çok çeşitli cebirlere ihtiyacınız var - çoklu tipleri kapsayan arayüz aileleri. OOP'u felsefi olarak sağlam buluyorum. Her şeyin bir nesne olduğunu iddia ediyor. Doğru olsa bile çok ilginç değil - her şeyin bir nesne olduğunu söylemek hiçbir şey söylemiyor. OOP'u metodolojik olarak yanlış buluyorum. Sınıflarla başlar. Sanki matematikçiler aksiyomlarla başlayacaklardı. Aksiyomlarla başlamıyorsunuz - kanıtlarla başlıyorsunuz. Sadece bir sürü ilgili kanıt bulduğunuzda, aksiyomlarla karşılaşabilirsiniz. Aksiyomlarla bitiyorsun. Programlamada da aynı şey geçerlidir: ilginç algoritmalarla başlamak zorundasınız. Sadece onları iyi anladığınızda,

Bu mekanizmanın neden temelde kusurlu olduğunu ve kullanılmaması gerektiğini anlamadan önce, kalıtım ve sanallar için biraz kullanım bulmaya çalıştım.

Stepanov algoritma kütüphanesini Nesneler ile değil, Genel Yineleyiciler ile ifade etti .


O yanlış ... çoğunlukla STL çok nesne yönelimli olduğu için ... Nesne terimden bu yana daha modern odaklı ...
AK_

1
@AK_ - Onun yanlış olduğunu düşünmüyorum. STL, terimin hiçbir anlamında yaklaşık OO bile değildir. STL'yi parametrik polimorfizm (örneğin Haskell veya SML) olan herhangi bir önemli şekilde değiştirmeye gerek kalmadan doğrudan OO olmayan bir dile çevirebilirsiniz.
Jules

2

Algoritmalar bilgisayarın ne yapması gerektiğini tanımlar. Yapı, algoritmanın [kaynak kodunda] nasıl düzenlendiğini açıklar. OOP, belirli "nesne yönelimli" yapılardan yararlanan bir programlama stilidir.

Algoritma kitapları genellikle yapıya değil algoritmaya odaklandıkları için OOP'dan kaçınırlar. Büyük ölçüde yapıya dayanan kod parçaları, bir algoritma kitabına koymak için zayıf örnekler olma eğilimindedir. Benzer şekilde, OOP kitapları genellikle algoritmayı engeller, çünkü hikayeyi karıştırırlar. OOP'nin satış noktası akışkanlığıdır ve bir algoritmaya sabitlemek daha katı görünmesini sağlar. Her şeyden çok kitabın odağıyla ilgili.

Gerçek hayat kodunda, her ikisini yan yana kullanacaksınız. Bilgisayar problemlerini algoritma olmadan tanımlayamazsınız ve yapı olmadan iyi algoritmalar yazmanın zor olduğunu görürsünüz (OOP veya başka türlü).

Nerede bulanıklaştıklarına bir örnek olarak Dinamik Programlamayı ele alalım. Bir algoritma kitabında, bir dizide homojen bir veri kümesinin nasıl alınacağını ve bir çözüme ulaşmak için Dinamik Programlamanın nasıl kullanılacağını açıklarsınız. Bir OOP kitabında Ziyaretçi gibi bir yapıya rastlayabilirsiniz, bu da bir dizi heterojen nesne üzerinde rasgele algoritmalar yapmanın bir yoludur. DP kitap örneği, nesneler üzerinde genel olarak aşağıdan yukarıya doğru çalışan çok basit bir Ziyaretçi olarak düşünülebilir. Ziyaretçi kalıbı bir DP sorununun iskeleti olarak düşünülebilir, ancak et ve patatesleri kaçırır. Gerçekte, sık sık ikinize de ihtiyacınız olduğunu göreceksiniz: Veri kümenizdeki heterojenlikle başa çıkmak için Ziyaretçi kalıbını kullanırsınız (DP bu konuda kötüdür) ve çalışma zamanını en aza indirmek için algoritmanızı düzenlemek için Ziyaretçi yapısı içindeki DP'yi kullanırsınız (Ziyaretçi kokan

Ayrıca tasarım modellerinin üstünde çalışan algoritmalar görüyoruz. Küçük bir alanda sözcük örnekleri daha zordur, ancak bir kez yapınız varsa, o yapıyı manipüle etmeye başlarsınız ve bunu yapmak için algoritmalar kullanırsınız.

Sadece OOP tarafından sunulabilecek ve çözülebilecek bazı sorunlar var mı?

Bu cevaplamak düşündüğünüzden daha zor bir soru. İlk siparişe göre, herhangi bir sorunu çözmek için OOP'a ihtiyacınız olan hiçbir hesaplama nedeni yoktur. Basit kanıt, her OOP programının kesin olarak OOP olmayan bir dil olan derlemeye indirilmesidir.

Bununla birlikte, daha büyük şemada, cevap evet doğru utangaç olmaya başlar. Yalnızca hesaplama yöntemleri ile nadiren sınırlanırsınız. Çoğu zaman denklemi etkileyen iş ihtiyaçları ve geliştirici becerileri gibi şeyler vardır. Bugün birçok uygulama OOP olmadan yazılamadı, OOP görev için bir şekilde temel olduğu için değil, OOP tarafından sağlanan yapı projeyi yolda ve bütçede tutmak için gerekliydi.

Bu, gelecekte komik yeni bir yapı için OOP'den asla vazgeçmeyeceğimizi söylemez. Sadece şaşırtıcı derecede büyük bir programlama görevi için bugün araç kutumuzdaki en etkili araçlardan biri olduğunu söylüyor. Gelecekteki sorunlar, gelişime farklı yapılar kullanarak yaklaşmamıza neden olabilir. Birincisi, sinir ağlarının "Nesneye Yönelik" olabileceği veya olmayabileceği çok farklı bir geliştirme yaklaşımı gerektirmesini bekliyorum.

Yakın gelecekte OOP'nin algoritma tasarımcılarının düşündüğü gibi yok olduğunu görmüyorum. Bugüne kadar, olağan örüntü, birisinin OOP'den yararlanmayan bir algoritma tasarlamasıdır. OOP topluluğu, algoritmanın OOP yapısına gerçekten uymadığını ve gerçekten gerekmediğini fark eder, bu nedenle tüm algoritmayı bir OOP yapısına sararlar ve kullanmaya başlarlar. Düşünün boost::shared_ptr. İçeride kalan referans sayma algoritmaları shared_ptrOOP dostu değildir. Bununla birlikte, desen shared_ptr, algoritmaların yeteneklerini OOP yapılandırılmış bir formatta ortaya çıkaran bir OOP sarmalayıcısı oluşturulana kadar popüler hale gelmedi . Şimdi, o kadar popüler ki C ++, C ++ 11 için en son özellik haline getirdi.

Bu neden bu kadar başarılı? Algoritmalar problemleri çözmede harikadır, ancak bunları nasıl kullanacaklarını anlamak için genellikle önemli bir ilk araştırma yatırımı gerektirirler. Nesneye Dayalı geliştirme, bu tür algoritmaların paketlenmesinde ve daha az başlangıç ​​yatırımı gerektiren bir arayüzün sağlanmasında çok etkilidir.


1

Büyük cevaplara ek olarak, OOP ve Algoritmalar arasında ek bir kavramsal ortaklığından bahsedeceğim .

Hem OOP hem de Algoritmalar , kodun doğruluğunu sağlamak için ön koşulların ve son koşulların kullanımını güçlü bir şekilde vurgular .

Genel olarak, bu bilgisayar biliminin tüm alanlarında standart bir uygulamadır; ancak bu yol gösterici ilke, OOP'de algoritmaların uygulanmasını karşılıklı olarak faydalı kılan evrimsel bir yolla sonuçlanır.

OOP'ta, bir arabirimi uygulamak için aynı sözleşmeyi (ön koşullar ve son koşullar) karşılayabilen bir grup nesne oluşturulabilir. Bu tür bir arayüz kullanıcısının, bazı nadir durumlar (sızan soyutlamanın gerçekleştiği) hariç, temel nesnede hangi uygulamanın kullanıldığını bilmesine gerek yoktur.

Algoritma, bir hesaplama yapmak için kullanılan ve önkoşulu alan ve postkoşulu üreten adımların uygulanmasıdır.

Bu nedenle, soyutlama fikrini önkoşullar ve sonşartlar şeklinde ödünç alabilir ve algoritmalara uygulayabilir. Bazen karmaşık algoritmaların daha küçük adımlara ayrılabileceğini ve bu daha küçük adımların, aynı ön koşullar ve son koşullar karşılandığı sürece farklı uygulama stratejilerine izin verebileceğini göreceksiniz.

OOP'de algoritmalar uygulayarak, bu daha küçük adımlar değiştirilebilir hale getirilebilir.

Son olarak, FP ve OOP'nin birbirini dışlamadığını unutmayın. Yukarıda açıklananlar FP için de aynı şekilde uygulanabilir.


Puanınız için teşekkürler! Dediğiniz gibi, algoritma sadece bazı adımlar ise, OOP daha soyut adımlar sunmamıza yardımcı olabilir. Sen "OOP algoritmaları uygulamak" işaret etti, ben her zaman yararlı mı sormak için sorum değiştirildi?
Ahmad

1
OOP'u "Sözleşme ile Tasarım" ile karıştırıyorsunuz. OOP olmadan çok faydalıdır ve çoğu OOP dili (C #, Java) bunun için gerçek bir destek sağlamaz (ön / sonrası koşullarını değil, basit arayüzleri destekler)
AK_

1
@AK_ Sözleşmeye Göre Tasarımın cevabımda açıklanan ortak özellik için doğru isim olduğunu kabul ediyorum. İddia ettiğim şey, bir tasarım paradigması olarak OOP'nin Sözleşme ile Tasarım'ı güçlü bir şekilde kucakladığı - sadece herhangi bir OOP ders kitabını okuyun. Orijinal cevabım da bu ortaklığın OOP için özel olmadığını belirtiyor.
rwong

-1
What is the relation between algorithms and OOP? Are they two independent topics?

Algoritmalar bir problemin nasıl çözüleceğiyle ilgilidir (Verilen girişten nasıl çıktı üretilir), OOP çözümümüzü nasıl formüle edeceğimiz veya ifade edeceğimizle ilgilidir (algoritmanın adımları).

Bir algoritma doğal dilde veya montaj dilinde tanımlanabilir, ancak doğal dilde sahip olduğumuz kavramlar bunu daha iyi yazmamıza ve anlamamıza yardımcı olur. Örneğin, kabarcık-sıralama algoritması şunlar olabilir:

bubbleSort(Array A)
  for (n=A.size; n>1; n=n-1){
    for (i=0; i<n-1; i=i+1){
      if (A[i] > A[i+1]){
        A.swap(i, i+1)
    } 
  } 
}

Bir OOP sözdizimi ve özelliği kullandığımızın ayrıntılarını gizlemek swapve onunla ilişkilendirmek için A, OO algoritmayı doğal dilimize ve anlayışımıza daha yakın hale getirir.

Are there some problems which can only be presented and solved by OOP?

Hayır, bir bilgisayardaki herhangi bir programın (veya algoritmanın) CPU ( Turing Machine ) üzerinde yürütülen bir dizi talimata çevrileceğini düşünürseniz ve bu talimatları bir bilgisayarda sorunu çözen nihai algoritma olarak görürsek , OOP başka bir şey yapamaz. Sadece insanın anlayışına ve muhakemesine yakınlaşır. Bu, prosedürlerimizi ve veri yapılarımızı paketlemenin bir yoludur.

How OOP can help algorithms? Or in which direction it can affect it?

Bir algoritmayı daha kolay veya daha anlaşılır hale getirmeye veya formüle etmeye yardımcı olabilir. Ayrıntıları gizleyebilir ve çözümün büyük bir resmini sağlayabilir.

Teorik olarak, algoritma ilk ve ikinci algoritmadır . Ancak gerçekte, algoritmayı izleyene veya beklenen çıktıyı üretene kadar beklendiği gibi çalıştığından emin olamayız. Bilgisayarlar bunu yapmamıza yardımcı olur, ancak bunu makine dilinde (derleme) yazmayı beklemezsiniz.

Bu bağlamda, OOP algoritmamızın bilgisayarlarda uygulanmasını, test edilmesini ve geliştirilmesini kolaylaştırır ve doğal dilimize yakın bir dilde bir bilgisayar için yazar.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.