ASP.NET kütüphanesi geliştirilirken yapılmış olan bazı tasarım hataları gerek öğrenenler gerekse de benim gibi anlatanlar açısından bela niteliğindedir. Örneğin Control taban sınıfında yer alan EnableViewState ya da Controls gibi bazı üyeler bu sınıftan türeyen tüm alt sınıflara kalıtım yoluyla aktarılmakta ancak hepsinde kullanılamamaktadır. Ekleyen : Aykut TAŞDELEN

Şöyle ki; EnableViewState isimli property doğal olarak hem DropDownList hem de TextBox'ta bulunmakta ancak DropDownList'te kendisine atanan False değeriyle kontrolün state bilgilerinin __ViewState isimli gizli alanda tutulması engellenmektedir. Öte yandan benzer atama TextBox için yapılırsa aynı sonuç elde edilemez zira TextBox state koruması için __ViewState'i, değil HttpHeader'ını kullanır. O halde bu property'nin TextBox'taki varlığı anlamsızdır hatta daha ötesi işlevi olmayan bir property'nin sırf taban sınıftan kalıtımla edilmiş olması ASP.NET'i öğrenen kişilerin aklında soru işaretlerine neden olmakta, bu durumun saçmalığını anlatmak da biz eğitmenlere düşmektedir.

Benzer bir durum Controls kolleksiyon property'si için de geçerlidir. Bilindiği gibi bir kontrolün child kontrollerini barındıran bu property'nin varlığı Panel gibi container ya da Label gibi düz HTML elemanı (span tag'i) üreten kontrollerde şüphesiz anlamlıdır. Ancak kendisine child kontrol eklenemeyecek olan TextBox için de bir o kadar anlamsızdır. Siz TextBox'ta bu kolleksiyona test amaçlı kontroller ekleseniz bile render edilemediklerini gözlemlersiniz. O halde bu property'nin de TextBox kontrolünde ne işi vardır ?

Bu sorular maalesef bir tasarım hatasından kaynaklanmaktadır. OOP tasarımda sadece kalıtım kullanmak Whitebox Reusability'e neden olur. Yani siz bazı alt sınıflarda kullanacağınız ama bazılarında kullanmayacağınız üyeleri taban sınıfa eklerseniz buradaki sonuçla karşılaşırsınız. O halde çözüm bu tür üyeleri taban sınıfa değil de türemiş sınıfa mı yazmaktır ? Şüphesiz hayır, zira bu şekilde de bakımı güç bir "yanlış" tasarıma daha neden olursunuz ! Doğru yöntem; Interface Segregation prensibi, ve/veya Decorator, Visitor gibi dizayn patern'lerini kullanmaktan geçer.

UML, Tasarım Prensipleri ve Dizayn Patern'leri konuları, C ve Sistem Programcıları Derneğinde yakında tarafımdan açılacak olan kursta ele alınacaktır. Ayrıca uzun bir süredir bu konulara ilişkin bir kitap üzerinde çalışmaktayım, kitabım C#, Java ve C++ dillerinde olacak.

Aykut TAŞDELEN

C ve Sistem Programcıları Derneği Eğitmeni

aykuttasdelen@csystem.org