Java Günlüğüm
Yazılım, Java, BT, azıcık felsefe, biraz mizah...
  • Udemy Eğitimleri
  • Temiz Kod
  • Tasarım Kalıpları
  • Hakkımda
  • Arşiv
RSS
17 Haziran 2014

“Java Kodunuzun Nesne Merkezli Olmadığının 10 İşareti” Başlıklı Konuşma

Akin Java, Kültür, Bilgi ve Düşünce, Yazılım Mühendisliği

Pek sevgili JavaTürk okurları 🙂

Burada yayınlamaya başladığım “Java Kodunuzun Nesne Merkezli Olmadığının 10 İşareti” başlıklı yazı dizisini, bir seferde keyifli bir ortamda dinlemek isterseniz, sizi 27 Haziran 2014 saat 14:00 – 16:00 arasında İTÜ Teknokent  ARI-3 binasındaki konferans salonuna beklerim.

java-teknokent

Bu konuşmayı, tanıdık tanımadık JavaTürk takipçisi arkadaşlarla yüzyüze görüşmek için de bir fırsat olarak görüyorum. Gelirseniz çok sevinirim 🙂

Görüşmek üzere.

Toplam görüntülenme sayısı: 1129

13 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
12 Haziran 2014

Java SE’den Sonra Ne Öğrenelim? İş Arayanlara Öneriler

Akin Java Java Öğren, Java öğrenmek

Sıklıkla, “hocam Java SE’yi biliyorum, şimdi üzerine ne öğrenmeliyim?” gibisinden sorulara muhatap oluyorum. Bu soruları soranların büyük bir kısmı ya yeni mezun ya da bir şekidle Java tarafına geçiş yapmaya çalışan ve kariyerinin başında olan, farklı teknolojileri kullanan yazılımcı arkadaşlar. Dolayısıyla bu konuyu hızlıca açıklığa kavuşturalım.

Bence öncelikle Java SE’yi bildiğinizden emin olun! Bu blogu takip edenler bilirler ki, bir başkasına sistematik olarak anlatamayacağınız şeyi bilmiyorsunuz demektir. Dolayısıyla bu blogda yazılmış Java öğrenmek üzerine pek çok yazıya ve Java Dersleri sayfasına bakılabilir. Eğer kendinizı Java SE konusunda çok iyi hissetmek istiyorsanız Java SE sertifikasyonunu almayı deneyebilirsiniz. Bu size neresinden baksanız altı ayınıza malolur ama sizi hem kendinize güven hem de iş bulma açısından çok güzel bir noktaya getirir. (Bu noktada bu blogda sertifikasyon konusu üzerine pek çok yazı yazıldığını hatırlatmak isterim.)

Mobil kısmı bir tarafa bırakırsak, kurumsal yani enterprise Java’dan bahsettiğimizde öncelikle web tarafından başlamakta fayda var gibi görünüyor. Java EE’nin web tarafında sonuçta servlet, JSP ve JSF var. Servlet ve JSP’lerin kullanımı gittikçe düşüyor. Özellikle servletlerin kullanımı düşüyor gibi görünse de hem aslında her şeyin temelinde olmasından dolayı hem de webin en temel protokolu olan HTTP’yi öğrenebilmek için servlet APIsini bilmekte fayda var. Bu sayede HTTP’nin yapısını, komutlarını, istek (request) ve cevap (response) nesnelerini, headerlarını, oturum (session) yapısını ve cookieleri öğrenmiş olursunuz. Sonrasında kullanımı servletlerden çok daha yaygın olan JSPlere geçip, EL ve JSTL’i de ele alıp, Java’da web tarafının temellerini güzelce öğrenebilirsiniz.

Temeller üzerine web tarafında kurgulanacak yapı bence MVC’dir. MVC, web tarafının en temel mimari kalıbı olup, hemen her web frameworkü tarafından uygulanmaktadır. Bu anlamda belki de en kolay öğrenilecek MVC frameworkü Spring MVCdir. Hem basit hem POJO yapısı hem de ayrı bir view teknolojisi barındırmaması açısından öğrenilmesi son derece kolaydır. Spring MVC’nin controller yapılarını ögrenerek ve JSP kullanarak hızlıca web uygulamaları yapabilirsiniz.

Eğer sertifika yolunda ilerliyorsanız, Java SE sertifikasından sonra Java’nın web teknolojilerinin sertifikasını almayı düşünebilirsiniz. Bu da sizin altı ay ya da bir senenizi alabilecektir, aklınızda bulundurun.

MVC konusunda Struts’ı da düşünebilirsiniz. Nispeten eski bir teknoloji olmasına rağmen hala pek çok yerde, özellikle 2000li yılların başında geliştirilmiş projelerde kullanılıyor. Spring MVC tabi olarak çok daha popüler ama Struts mimari açıdan daha şeffaf, arka planda ne olup bittiğini anlamak açısından daha keyifli ve ufuk açıcıdır. Her halükarda iyi bir MVC frameworkü hem size temel mimariyi öğretecek hem de CVnizde güzel duracaktır.

Spring MVC’ye çok iyi bir MVC alternatifi JSF olabilir. JSF aynı zamanda bir view teknolojisi de olduğundan pek çok farklı JSF bileşen kütüphanesi vardır. JSF öğrenmek demek aslında biraz da bu kütüphanelerden birisiyle çalışmak demektir. Bu anlamda öncelikle Java EE ile gelen referans JSF implementationu (mojorra) ile başlayıp sonrasında Türkiye’den arkadaşlarımızın başarıyla geliştirip, yazılım sektöründe sundukları Primefaces ile devam etmek güzel olacaktır. Bununla birlikte JSF, hayat döngüsü (life-cycle) Spring MVC’ye göre daha karmaşık ve soyut olduğundan, ayrıca event, validation vb. yapıları da deklaratif olarak hallettiğinden ögrenilmesi Spring MVC’ye göre daha zordur ve uzun zaman alır. Lakin bence JSF, Spring MVC’den çok daha güçlü ve hızlı geliştirmeye elveren bir teknoloji olduğundan, vakti olan ve zoru sevenlerin Spring MVC yerine JSF ile devam etmelerinde fayda vardır. Zaten piyasadaki eğilim de daha çok JSF yönündedir. Bu yüzden JSF’e giriş yapmış bir Javacının iş bulmada pek zorlanmayacağını düşünüyorum.

İster JSF ister Spring MVC kullanın, öğrenmeden kaçamayacağınız bir konu daha var: Nesneler arasındaki bağımlılıkları yönetmek için dependency injection (DI). İster Spring DI’yi öğrenin ister daha iyi bir alternatif ve yapı olan Java CDI öğrenin ama sadece web tarafında geliştirme yapsanız bile yüksek bir ihtimalle bir DI yapısı kullanacağınızı unutmayın.

Web tarafını müteakiben öğrenilecek bir başka konu da veri tabanı ile iletişimde bulunan kalıcılık (persistence) katmanına yönelik teknolojiler olabilir. JDBC, java SE’nin bu konudaki en temel bileşeni. Dolayısıyla JDBC’yi pişirmek, hatta Spring’in JDBC desteğini kullanmak ve orada DAO kalıbını uygulayacak şekilde programlarınızı kurgulamak bence iş bulmada çok temel bir kazanımdır.

JDBC’den sonra JPA’e girişmek, piyasada en çok kullanılan kalıcılık çerçevelerinden birini kullanmak anlamına geleceğinden iş bulma ihtimalinizi çok arttıracaktır. JPA, temelelrinin öğrenilmesi zor olmayan ama içine daldıkça karmaşıklaşan bir teknoloji olduğu içın temel eşleştirme (mapping) yapıları, EntityManager APIsi ile transaction yönetimini bilseniz size çok avantaj sağlayacak bir duruma gelebilirsiniz.

JPA ile uğraştıktan sonra gerektiğinde Hibernate’in native API’si ile de rahatlıkla uğraşabilirsiniz. Hibernate, JPA’den daha eski bir yapı ama kavramsal oalrak aynı işi yapıyorlar hatta çok benzer şekilde yapıyorlar. Bu yüzden bu durum iş bulma ihtimalinizi çok arttıracaktır.

Zorunlu olmamakla beraber, bütün bu konularla uğraşırken ilgili tasarım kalıplarını da yavaştan ele alıp, o konularda da bir şeyler öğrenirseniz mükemmel olacaktır.

Tabi yukarıda bahsettiğim teknolojilerde belli bir noktaya gelmek sizin bir senenizi rahatlıkla alacaktır. İşin içine sertifikasyonu da sokarsanız, sadece ilk yani Java SE sertifikasını almak bile rahatlıkla 6 ayınızı alabilir. Bu biraz da ne kadar vakit ayırabildiğinizle ilgili bir durumdur. Ama bence her halukarda bu korkulacak bir durum değildir çünkü gerek okulunuzun son senesinde, gerek ise okuldan sonra hasbel kader girdiğiniz ama çok da mutlu olmadığınız ilk işinizde kendinizi bu konularda geliştirecek zaman bulabilirsiniz.

Gördüğüm şu: bilen, iyi bir hedefe ve vizyona sahip ve kendine güvenen kişiler, iş tecrübeleri olmasa bile çok güzel işler bulmaya devam ediyorlar.

Toplam görüntülenme sayısı: 8791

66 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
11 Haziran 2014

Kod Dokümantasyonu ve JavaDoc Üzerine – II

Akin Java, Yazılım Mühendisliği JavaDoc, Kod dokümantasyonu

Bir önceki yazıda JavaDoc açıklamalarının nasıl yazılacağından ve javadoc aracını kullanarak API dokümanının nasıl üretileceğinden bahsetmiştik. Bu yazıda bu konuyu sonlandıralım.

Kodunuzu bu şekilde dokümante etmeniz, kodunuzun APIsini çıkarmak anlamına gelir. API dokümantasyonu, kodun iç çalışma şeklinin açıklanması anlamına gelmez. Aksine, kodunuzu dışarıdan kullanacak kişi için, kodun iç yapısına girmeden sadece arayüz seviyesinde doküman sağlar.

Sağlıklı yazılan kodlar için aslında çoğu zaman API dokümantasyonu yeterlidir. Eğer kodunuzu karmaşık değil de basit yazarsanız, uzun kodlarınızı farklı metotlara ve sınıflara bölerseniz, metotlarınıza olabildiğince az parametre geçerseniz,  hem metotlarınız hem de sınıflarınız son derece yalın, kısa ve anlaşılır olacaktır. Bu sayede JavaDoc, kodunuzun anlaşılması için yeterli olacaktır. Aksine metotlarınızı ve sınıflarınızı uzun ve karmaşık tutarsanız şu iki durumdan birisini yapmak zorunda kalırsınız: Ya JavaDoc dokümantasyonunda kodunuzun iç çalışması ile ilgili detay verirsiniz ki bu kesinlikle istenen bir şey değildir, ya da kodunuzda JavaDoc dışında “//” ya da “/*   */” ile API’de gözükmeyecek açıklamalar yazarsınız.  Kodunuzu ne kadar yalın, basit ve anlaşılır kurgulayıp yazarsanız JavaDoc dışında o kadar az iç dokümantasyon yaparsınız. Yapacağınız JavaDoc açıklamaları hem müşterileriniz hem de sizin kendiniz için yeterli olur.

Yukarıdaki tartışmadan kodunuz için API dışında bir iç açıklama yapmayın demiyorum. Her halukarda zaman zaman “//” ya da “/*   */” ile açıklama yapmak zorunda kalabiliriz. Ama unutmayın ki ne kadar basit ve kısa kod yazarsanız bu türden açıklamalara o kadar az ihtiyaç duyarsınız. Yani kodunuz, var olduğu haliyle kendini yeterince açıklıyor demektir.

JavaDoc o kadar önemli ki, örneğin  bir framework kullanmaya giriştiğimizde ya da bir component satın aldığımızda/indirdiğimizde dokümantasyon olarak ilk bakacağımız şey API dokümantasyonu olmalıdır. Bir yazılım evi ile bir proje için anlaştığımızda, bize teslim edilecek kod yanında JavaDoc’un da hazırlanması gerektiğini anlaşmada belirtmemiz gereklidir. Kodu devralırken, kod ile birlikte API dokümantasyonunu devralmalı, eğer bir eğitim de söz konusu olacaksa, API de bu eğitimin ciddi bir parçası olmalıdır.

Eğer yazılım geliştiriyorsanız, hem kendiniz hem de arkadaşlarınız için JavaDoc yazmalısınız. Bu şekilde sizin kafanızdaki o yapıyla ilgili bilginin, rahatlıkla başkaları tarafından hızlıca kazanılmasını sağlamış olursunuz. Eğer hic bir şekilde dokümante edilmemiş bir kod devralmışsanız, kodun her dokunduğunuz yerine JavaDoc yazarak, biriktirmeye başladığınız bilginizi, kalıcı ve paylaşılabilir hale getiriyorsunuz demektir. Bir müddet sonra tüm kodun dokümante edildiğini gördüğünüzde çok güzel bir iş yapmış olduğunuzu ve bakımı anlama yönünden kolaylaştırdığınızı farkedeceksiniz.

Peki JavaDoc’u kim kullanıyor dersiniz? İşin açıkçası Javacılar, var olan JavaDocları bile düzenli bir şekilde kullanmıyorlar, bırakın yazmayı. Halbuki diyelim ki Spring gibi bir frameworkü öğreniyorsunuz, JavaDoc’u elinizin altında olmalı. Hibernate’in yeni versiyonunu indirdiniz, JavaDoc’unu da indirip, bütün dokümantasyonlarınızı koyduğunuz yere koyun örneğin ve yerini de tarayıcınıza kısa yol olarak kaydedin öyle ki tarayıcınızda Java diye bir folder olsun ve altında her türlü Java yapısının API’lerine kısa yollar olsun. Tabi ki en temel olması gereken kısa yollar ise Java SE ve Java EE API’leri icin olmalı. Uzun lafın kısası, makinanızda kendisiyle geliştirme yaptığınız her Java yapısı için, framework olsun component olsun, utility vb. olsun, elinizin altında o yapıların JavaDoc’larını bulundurmalısınız.

Ben eğitim ya da danışmalık verdiğim zamanlar, özellikle ele alacağımız konularla ilgili APIleri muhakkak katılımcılara dağıtıyor ve tarayıcılarından hızlıca ulaşılır hale getirmelerini rica ediyorum. İlgili APIleri webden nasıl indireceklerini açıklıyorum. Zira APIden haberdar olmadan geliştirme yapan o kadar çok Javacıyla karşılaşıyorum ki her seferinde böyle güzel bir araç varken neden körleme ve son derece verimsiz bir kod geliştirme yöntemine sahibiz diye düşünmeden edemiyorum.

Çok sık karşılaştığım sahne şu: Geliştirme ortamının (IDE) editöründe bir referans yazılıp sonuna “.” basılır, sonra da IDE’nin çıkardığı listeden bir metot seçilir ve derlenip çalıştırılır. Eğer bir problem çıkmazsa ne ala. Yok problem çıkarsa seçilen metot silinir ve tekrar “.” konup çıkan listeden bir başka metot seçilir. Eğer ilgili nesnenin APIsini biliyor da sadece hatırlamak için bu yöntemi kullanıyorsak bir problem yok. Ama nesnenin ne işe yaradığını bilmiyorsak, APIsine bakmak yerine bu şekilde hızlıca doğru metodu denk getirmeye çalışıyorsak işimiz vahim demektir. Şahsen ben böyle kod geliştiren bir developerın koduna güvenmem.

Bir kere JavaDoc’u kullanın ve yarattığı etkiyi görün, bence bir daha vazgeçemeyeceksiniz. Aslında çoğu zaman sadece bilmediğimiz, tecrübe etmediğimiz için korkup kullanmıyoruz. Unutmayın, kullandıgımız Java SE, ME, EE ve her türlü Spring, Hibernate vb. frameworklerin API dokümanları, sadece ve sadece bu yapıları geliştiren developerların, geliştirme esnasında yazdıkları açıklamalardan oluşuyor. Çünkü kod dokümantasyonu olsa olsa ancak kodu yazarken yapılabilir.

Bence Google programcılığını engellemenin en temel yolu, Javacılar için API kullanımını vazgeçilmez bir alışkanlık haline getirmekten geçer.

Bol JavaDoclu günler dilerim 🙂

 

Toplam görüntülenme sayısı: 2163

13 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
11 Haziran 2014

Kod Dokümantasyonu ve JavaDoc Üzerine – I

Akin Java, Yazılım Mühendisliği Java Dokümantasyon, JavaDoc, Kod dokümantasyonu

Soyut ve karmaşık olan yapısından dolayı yazılım geliştirme sürecindeki en temel problem anlama-anlaşma problemidir. Bu problemi gidermek için ne yapılsa yeridir. Dokümantasyon da bu problemi gidermenin en temel yollarından birisidir. Tabi olarak yazılım geliştirme sürecinin farklı kısımlarının farklı türde dokümantasyona ihtiyaç vardır. Analiz sürecindeki dokümantasyon ile mimari çalışmalardaki ya da kodlamadaki dokümantasyonun farklı içerikte ve formatta olması kaçınılmazdır.

Sanırım tüm dünyada yazılım dokümantasyonu pek sevilen ve özen gösterilen bir konu değildir. Hele konu kod dokümantasyonu olunca, hiç bir yazılım geliştiricinin bunu severek yaptığını düşünmüyorum. Aslında kesinlikle kod yazmak kadar zevkli olmayan bu tür çalışmaların, zekasının sınırlarında gezmekten haz alan geliştiriciler için çok çekici olmadığının da farkındayım. Ama bu kadar karmaşık ve soyut yapıların anlaşılmasını sağlamak ve bu anlaşılmayı sürdürebilmek, kalıcı kılmak için, her şeyden önce, kendi çalışmamızı kolaylaştırmak, kendimize yardım etmek için kodumuzu dokümante etmemiz lazım.

Java, kodun API dokümantasyonu için ta başından bu yana JavaDoc isimli bir yapıya sahiptir. JavaDoc hem kod dokümantasyonu hem de API dokümantasyonu için nefis bir araçtır. Sonrasında çıkan C# ya da Scala gibi diller de benzer yapılar oluşturuldu zaten.

JavaDoc, kod için API dokümantasyonu yazmak için bize bir format sunar. Bu formatta HTML etiketleri kullanılabileceği gibi JavaDoc’un kendine has “@author” ya da “@see” gibi etiketleri de kullanılabilir.

JavaDoc dokümantasyonunu, class, interface ya da enum tiplerinden önce, nesne ve sınıf değişkenlerinden önce ve constructorlar dahil olmak üzere metotlardan önce, /** */ formatında yazılır. Yani JavaDoc yorumlarınız, “/**” ile başlamalı ve “*/” ile bitmelidir. JavaDoc yazarken HTML kullanabilirsiniz çünkü zaten nihayetinde üretilecek olan doküman bir HTML dokümanıdır.

Örneğin Bulp isimli bir sınıfı, bu sınıfın tanımlandığı yerde JavaDoc ile şöyle açıklayabiliriz.

package org.javaturk.oop.ch08;

/**
*  A <code>Bulp</code> is a bulp.
 * This class simulates a bulp. It has a default constructor that creates a bulp
 * with a max luminescence of 60 and another constructor that creates a bulp with
 * specified max luminescence.
 * <p>
 * This class has methods to turn on and turn off the bulp and to increase and 
 * to decrease the current luminescence of the bulp.
 *
 * @author Akin Kaldiroglu
 * @version 1.3.7
 * @see <a href="http://www.javaturk.org">JavaTurk.org</a>
 * @since 1.2
 */
public class Bulp{
    
	public static final int STANDARD_MAX_LUMINESCENCE = 60;
    String name;
    private int currentLuminescence;
    protected int maxLuminescence;
    
    /** Creates a new Bulp object with standard luminescence. */
    public Bulp() {
        maxLuminescence = STANDARD_MAX_LUMINESCENCE;
        currentLuminescence = 0;
        System.out.println("A bulb with max luminescence of " + maxLuminescence + " created.");
    }
    
    /** 
     * Creates a new Bulp object with specified max luminescence
     * @param maxLuminescenceValue Max luminescence of the bulp
     */
    public Bulp(int maxLuminescenceValue) {
        maxLuminescence = maxLuminescenceValue;
        currentLuminescence = 0;
        name = "bulb" + new String((new Integer(maxLuminescence)).toString());
        System.out.println("A bulb " + name + " with max luminescence of " + maxLuminescence + " created.");
    }
    ...
}

Yukarıdaki örnekte Bulp sınıfının JavaDoc ile dokümante edilmiş hali var. Görüldüğü gibi dört farklı JavaDoc etiketi kullanılmış durumda. Ayrıca Bulp’ın içinde tanımlanmış üç tane de değişken var. Bu üç değişken ise, JavaDoc’un bazı özelliklerini göstermek üzere, farklı erişim seviyelerinde tutulmuşlardır.

Aşağıda Bulp sınıfının metotlarının JavaDoc ile dokümante edilmiş hali görülmektedir:

...
    
    /** 
     * Sets max luminescence to specified value
     * @param value Specified max luminescence  
     * @exception IllegalArgumentException in case of passing non-positive argument.
     */
    public void setMaxLuminescence(int value) throws IllegalArgumentException{
    	if(value <= 0)
    		throw new IllegalArgumentException("Luminescence value passed must be greater than zero: " + value);
        maxLuminescence = value;
    }
    
    /** 
     * Gets max luminescence of the bulp.
     * @return max luminescence.
     */
    public int getMaxLuminescence(){
        return maxLuminescence;
    }
    
    /** 
     * Turns on the bulp.
     * Curent luminescence is set to max luminescence.
     */
    public void on(){
        currentLuminescence = maxLuminescence;
        System.out.println("Bulb  " + this.name + " is on now");
    }
    
    /** 
     * Turns off the bulp.
     * Curent luminescence is set to 0.
     */
    public void off(){
        currentLuminescence = 0;
        System.out.println("Bulp  " + this.name + " off now");
    }
    
    /** Just brightens the bulp. */
    public void brighten(){
        System.out.println("Bulb  " + this.name + " is brighter now");
    }
    
    /** 
     * Brightens the bulp to specified value.
     * @param value New luminescence of the bulp.
     * @exception IllegalArgumentException in case of passing non-positive argument.
     */
    public void brighten(int value) throws IllegalArgumentException{
    	if(value <= 0)
    		throw new IllegalArgumentException("Luminescence value passed must be greater than zero: " + value);
    	
        if(currentLuminescence < value){
            if(value <= maxLuminescence){
                currentLuminescence = value;
                System.out.println("Luminescence of " + this.name + " is increased to " + currentLuminescence);
            }
            else{
                System.out.println("Max luminescence of " + this.name + " is " + maxLuminescence);
            }
        }
        else{
            System.out.println("Do you want to make " + this.name + " brighter or dimmer?");
            System.out.println("Current luminescence of " + this.name + " is " + currentLuminescence);
            System.out.println("You tried to brighten it to " + value);
        }
    }
    
    /** Just dims the bulp. */
    public void dim(){
        System.out.println("Bulb  " + this.name + " is dimmer now");
    }
    
    /** 
     * Dims the bulp to specified value.
     * @param value New luminescence of the bulp
     */
    public void dim(int value) throws IllegalArgumentException{
    	if(value <= 0)
    		throw new IllegalArgumentException("Luminescence value passed must be greater than zero.");
    	
        if(currentLuminescence > value){
            if(value >= 0){
                currentLuminescence = value;
                System.out.println("Luminescence of " + this.name + " is decreased to " + currentLuminescence);
            }
            else{
                System.out.println("Don't be that silly! I am just a bulb not a black hole");
            }
        }
        else{
            System.out.println("Do you want to make " + this.name + " brighter or dimmer?");
            System.out.println("Current luminescence of " + this.name + " is " + currentLuminescence);
            System.out.println("You tried to dim it to " + value);
        }
    }  
}

Burada da metotlara geçılen parametrelerin “@param”, döndürülen değerlerin “@return” ve fırlatılan sıra dışı durumların ise “@exception” etiketleriyle nasıl dokümante edildiği görülmektedir.

Bu şekilde JavaDoc ile dokümante edilmiş olan kodunuzu, JDK ile birlikte gelen javadoc aracıyla HTML dokümantasyonu haline getirebilirsiniz. Bunun için yapmanız gereken java kaynak kodunu ya da class bytecodeunu kullanmaktır. Bunun için aşağıdaki gibi bir komut satırını kullanabilirsiniz:

javadoc -d doc Bulp.java

Bu komut ile Bulp.java dosyasında var olan Bulp sınıfının APIsini “doc” isimli bir dosyaya çıkarabilirsiniz. Bu durumda elde edilen API dokümanı şöyledir:

Bulp sınıfının APIsi.

Bulp sınıfının APIsi.

 

Oluşturulan bu nefis doküman, sizin kodunuzu yazarken girdiğiniz JavaDoc formatına uygun açıklamalardan oluşturulmuştur. Bu dokümanda örneğin sadece public ve protected olarak belirtilen alanlar görünmektedir. Benzer şekilde version ve author alanları da görünmemektedir. Bu alanların da görülmesini sağlamak için javadoc aracını çalıştırırken “-author” gibi ilgili flag değerlerini de geçmeniz gereklidir.

Oracle’in sayfalarında, burada ve burada JavaDoc kullanmak için nasıl açıklama yazılabileceği detaylıca anlatılıyor. Burada da JavaDoc’un resmi sayfası var.

Bu konuya bir sonraki yazıda devam edelim.

Toplam görüntülenme sayısı: 2861

18 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
«< 40 41 42 43 44 >»

Günlüğüme Hoşgeldiniz

Bu günlükte, Yazılım Mühendisliği, Bilgi Teknolojileri, Java, kişisel gelişim ve zaman zaman da diğer konulardaki düşüncelerimi sizlerle paylaşacağım. Umarım beğenir ve hoşça vakit geçirirsiniz.

Her türlü düşüncenizi, yorum olsun, beğeni ya da eleştiri olsun, bana iletmenizi rica ediyorum sizden. Ayrıca bana akin@javaturk.org adresinden ya da Twitter'dan ulaşabilirsiniz. Videolarıma da buradan ulaşabilirsiniz.

Teşekkür ederim.

Akın Kaldıroğlu

Rahat Okumak İçin

A Decrease font size. A Reset font size. A Increase font size.

Sosyal Medya

  • Twitter
  • Facebook
  • LinkedIn
  • Youtube

Son Twitlerim

→ Takip Etmek İçin

Abone Olun

Emalinizi girerek yazılardan haberdar olun.
Loading

Son Yazılarım

  • Udemy Eğitimlerim Üzerine
  • (başlıksız)
  • Clean Code / Temiz Kod Eğitimi Udemy’de
  • Java ile Nesne-Merkezli Programlamaya Giriş Eğitimi Udemy’de
  • Selsoft Video Eğitimleri
  • Spring ile Kurumsal Yazılım Geliştirme
  • Corona Günlerinde Design Patterns
  • Corona Günlerinde Java
  • JDK 10 ve “var” Özelliği
  • Onur Özcan
  • Analist ve İş Bilgisi
  • Farklı Dillerin Bakış Açısıyla Nesne-Merkezli Programlama
  • Java Nedir?
  • Bilgi Teknolojilerinde Yetenek Yönetimi – II: Tanımlar ve Eleştiriler – I
  • Alelade Hikayeler – II: Bir Başka Performans Problemi

Yazı Kategorileri

Yazı Takvimi

Mart 2026
P S Ç P C C P
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
« May    

Yazı Arşivi

Blogroll

  • Binnur Kurt'un Günlüğü
  • Ender'in Java Blogu
  • Erdem Seherler
  • Kızımın Günlüğü
  • Kurumsal Java
  • Levent Karagöl
  • Levent'in Java Blogu
  • Mert Can Akkan’s java tips,options, news…
  • Yaşar Safkan
  • Yasin Saygılı
  • Yazı Dünyası

Yazı Etiketleri

analiz Bilmek C Desen design pattern EJB Eğitim Fortran Hibernate Java Java'ya nasil baslarim Java dersleri Java EE Java Persistence API Java SE Java Sertifika Java Öğren Java öğreniyorum Java öğrenmek JPA Kalıp Kurumsal Java nesne nesne-merkezli No Silver Bullet object object-oriented Oracle Java Certifications pattern performans programlama programlama dilleri programlama nedir sertifika singleton tasarım tasarım deseni tasarım desenleri tasarım şablonu yazılım yazılım geliştirme Yazılım Mühendisliği yazılımın doğası yazılımın zorlukları Şablon

↑

© Java Günlüğüm 2026
Powered by WordPress • Themify WordPress Themes
 

Yorumlar Yükleniyor...