semaver
New member
Soyutlama ile ilgili tartışmalar çok soyut olabilir. Ancak tam olarak soyutlamanın ne anlama geldiğini ve geliştiricilerin ve mimarların ne elde ettikleri.
Bu sefer soyutlama konusunda biraz felsefi bir düşünce treni. Fırsat, son yayınlarımdan birinde bir tartışma oldu. Genel olarak soyutlama ve özellikle iyi soyutlama hakkında canlı bir fikir alışverişi vardı. İyi öneriler için Ometadanw'a özel teşekkürler.
Wikipedia'ya göre, soyutlama bilgi teknolojisinde bir hedef olarak tanımlanır.
Programlama dilinden veya kitaplıklardan soyutlamalar kullanılarak bir programdaki (genellikle bilgiye dikkat ederek) bilgilerin çoğaltılmasında pratik azalma.
Bu, örneğin, her sınıfın veya prosedürün bir soyutlamayı temsil ettiği anlamına gelir. Basitçe söylemek gerekirse, kuru prensiple uğraşıyoruz (tekrar etmeyin).
Webopedi de soyutlamadan kapsüle ve gizli prensibe yakın bir ilişki görüyor. Bu tanım, gerçekten doğru olsa bile henüz hiçbir şey kazanmamıştır.
Psödofilosofik konusuna başlarsanız, aşağıdaki tanım vardır (Wikipedia).
Ana önemine göre, soyutlama kavramsal süreci, genel kuralları ve somut örneklerin kullanımı ve sınıflandırılması kavramlarını, kelimelerin, ilkelerin veya diğer yöntemlerin kullanımını tanımlar. “Soyutlama” bu sürecin sonucudur: bir grup, alan veya kategoride ilgili kavramları birleştiren tüm alt kavramlar için süper kategorizasyon kavramı olarak bir kavram olarak.
Genel olarak, daha yüksek bir kategori için ilişkili kavram grubunun soyutlama olduğu ve tasarımda işe yaramaz bir azalmanın önlenmesine yardımcı olduğu söylenebilir. Bu bağlamda, şimdi daha akıllıyız, ama fazla değiliz.
Yazılımın geliştirilmesinde sürekli soyutlama ile ilgileniyoruz. Disiplinimizde sınıf, ağaç, pencere, sprint gibi bir metafor enflasyonu hiç değildir. Metaforlar hakkındaki tartışmalarda, bilgi “bir görüntü 1000'den fazla kelime söylüyor” genellikle odaya atılır. Ancak bu noktada, her şeyin diğer tarafta çalıştığı söylenmelidir: “Bir kelime 1000'den fazla görüntü söylüyor”. Ancak, her iki ifade de aynı arka plana sahiptir. Bir metafor olarak formüle edilen bir soyutlama, kavramsal olarak ilgili nesnelerin tamamı kategorisidir.
Fakat soyutlamalar ne zaman mantıklı ve ne zaman değil?
Bence, makul soyutlamanın en iyi örneği yazılım modelleridir. Gözlemci modelini alalım. Tasarımda göründüğü anda bunun ne anlama geldiğini biliyoruz. Bu, bir mimariye girmenizi kolaylaştırır, çünkü artık ayrıntıları girmek zorunda değilsiniz. İyi metaforlar sayesinde tasarım çok hızlı bir şekilde açılıyor. Modeller bir dilin isimlerini oluşturur, tabiri caizse.
Soyutlama açıkça bağlama uyum sağlamalı ve tutarlı olmalıdır. Bir mimaride ezilmiş bir gözlemci modeli, uygulamanın bağlamı uyum sağlamaz, ancak mimariyi anlamak için çalışır. Bir singleton modeli uygulanabilir, ancak küresel koşullara ve dolayısıyla şeffaf projelere yol açar.
En iyi durumda, soyutlamalar anlaşılabilir bir dil oluşturur. Soyutlama bir ada değildir, ancak özellikle diğer soyutlamalarla uyumlu bir şekilde uyumlu hale gelebiliyorsa özellikle etkilidir. Örneğin, model ekran denetleyicisinin bir parçası olarak gözlemci. Veya nakliyeci, vekil ve broker modeli için alıcı kombinasyonu.
Seçilen soyutlamalar ve metaforlar, mantıklı kesintiler olmadan bir hikaye turu anlatmalıdır. Aynı nedenden ötürü, hedef grubu için bir miras hiyerarşisi – geliştirici, test cihazı – anlaşılması kolay ve kullanılabilir olmalıdır.
Patchworks ile değil
Bu Patchwork mimarisi için geçerli değildir. Sürekli bakımı olmayan en iyi mimarilerin de erchwork olduğu için çok aptalca. Mimari soyutlamaları olumsuz etkilerden korumak çok çaba sarf ediyor ve tüm kuruluşlar bunu bağışlamaya hazır değil. Bu arada, bu da soyutlamalarla dolu programlama dillerinde de gözlemlenebilir.
Deyimsel yaklaşım özellikle çerçeve, kütüphaneler, sınıflar, bileşenler için geçerlidir, çünkü bu varlıklar projeler veya uygulamaların kurucu unsurları tarafından hizmet vermektedir. Bu, basit kullanılabilirlikleriyle ilgili büyük beklentiler olduğu anlamına gelir. Bu eserlerin tüketicisi anlamlarını mümkün olan en iyi şekilde geliştirmelidir. Minimal sürpriz ilkesi her zaman tonu vermelidir. Sonuçta, kimse ilk önce çalışma talimatlarını okuması gereken bir çekiç satın almak istemez. .NET veya JDK gibi çerçeve buradaki modeller arasındadır.
Bir soyutlamanın kalitesini objektif olarak değerlendirmek mümkün müdür? Sadece kısmen. Bununla birlikte, araçlar semantiği içermediği sürece bu değerlendirme otomatikleştirilemez. Peki ya öznel bir değerlendirme? Çalışır, ancak tanımlanmış bir uygulama bağlamında gerçekleşmelidir. Örneğin, anlaşılabilirlik ve tasarım yönetimi açısından.
Bu nedenle soyutlama, soyutlamaların uyumlu bir yapısına dahil edilmelidir. Ek olarak, soyutlamalar uygulamanın bağlamına kıyasla kendi kendine yetersiz olmalıdır. Soyutlama, bir hedef gruba iyi ve neredeyse kendiliğinden açılan deyimsel bir dilin temelidir.
()
Bu sefer soyutlama konusunda biraz felsefi bir düşünce treni. Fırsat, son yayınlarımdan birinde bir tartışma oldu. Genel olarak soyutlama ve özellikle iyi soyutlama hakkında canlı bir fikir alışverişi vardı. İyi öneriler için Ometadanw'a özel teşekkürler.
Wikipedia'ya göre, soyutlama bilgi teknolojisinde bir hedef olarak tanımlanır.
Programlama dilinden veya kitaplıklardan soyutlamalar kullanılarak bir programdaki (genellikle bilgiye dikkat ederek) bilgilerin çoğaltılmasında pratik azalma.
Bu, örneğin, her sınıfın veya prosedürün bir soyutlamayı temsil ettiği anlamına gelir. Basitçe söylemek gerekirse, kuru prensiple uğraşıyoruz (tekrar etmeyin).
Webopedi de soyutlamadan kapsüle ve gizli prensibe yakın bir ilişki görüyor. Bu tanım, gerçekten doğru olsa bile henüz hiçbir şey kazanmamıştır.
Psödofilosofik konusuna başlarsanız, aşağıdaki tanım vardır (Wikipedia).
Ana önemine göre, soyutlama kavramsal süreci, genel kuralları ve somut örneklerin kullanımı ve sınıflandırılması kavramlarını, kelimelerin, ilkelerin veya diğer yöntemlerin kullanımını tanımlar. “Soyutlama” bu sürecin sonucudur: bir grup, alan veya kategoride ilgili kavramları birleştiren tüm alt kavramlar için süper kategorizasyon kavramı olarak bir kavram olarak.
Genel olarak, daha yüksek bir kategori için ilişkili kavram grubunun soyutlama olduğu ve tasarımda işe yaramaz bir azalmanın önlenmesine yardımcı olduğu söylenebilir. Bu bağlamda, şimdi daha akıllıyız, ama fazla değiliz.
Yazılımın geliştirilmesinde sürekli soyutlama ile ilgileniyoruz. Disiplinimizde sınıf, ağaç, pencere, sprint gibi bir metafor enflasyonu hiç değildir. Metaforlar hakkındaki tartışmalarda, bilgi “bir görüntü 1000'den fazla kelime söylüyor” genellikle odaya atılır. Ancak bu noktada, her şeyin diğer tarafta çalıştığı söylenmelidir: “Bir kelime 1000'den fazla görüntü söylüyor”. Ancak, her iki ifade de aynı arka plana sahiptir. Bir metafor olarak formüle edilen bir soyutlama, kavramsal olarak ilgili nesnelerin tamamı kategorisidir.
Fakat soyutlamalar ne zaman mantıklı ve ne zaman değil?
Bence, makul soyutlamanın en iyi örneği yazılım modelleridir. Gözlemci modelini alalım. Tasarımda göründüğü anda bunun ne anlama geldiğini biliyoruz. Bu, bir mimariye girmenizi kolaylaştırır, çünkü artık ayrıntıları girmek zorunda değilsiniz. İyi metaforlar sayesinde tasarım çok hızlı bir şekilde açılıyor. Modeller bir dilin isimlerini oluşturur, tabiri caizse.
Soyutlama açıkça bağlama uyum sağlamalı ve tutarlı olmalıdır. Bir mimaride ezilmiş bir gözlemci modeli, uygulamanın bağlamı uyum sağlamaz, ancak mimariyi anlamak için çalışır. Bir singleton modeli uygulanabilir, ancak küresel koşullara ve dolayısıyla şeffaf projelere yol açar.
En iyi durumda, soyutlamalar anlaşılabilir bir dil oluşturur. Soyutlama bir ada değildir, ancak özellikle diğer soyutlamalarla uyumlu bir şekilde uyumlu hale gelebiliyorsa özellikle etkilidir. Örneğin, model ekran denetleyicisinin bir parçası olarak gözlemci. Veya nakliyeci, vekil ve broker modeli için alıcı kombinasyonu.
Seçilen soyutlamalar ve metaforlar, mantıklı kesintiler olmadan bir hikaye turu anlatmalıdır. Aynı nedenden ötürü, hedef grubu için bir miras hiyerarşisi – geliştirici, test cihazı – anlaşılması kolay ve kullanılabilir olmalıdır.
Patchworks ile değil
Bu Patchwork mimarisi için geçerli değildir. Sürekli bakımı olmayan en iyi mimarilerin de erchwork olduğu için çok aptalca. Mimari soyutlamaları olumsuz etkilerden korumak çok çaba sarf ediyor ve tüm kuruluşlar bunu bağışlamaya hazır değil. Bu arada, bu da soyutlamalarla dolu programlama dillerinde de gözlemlenebilir.
Deyimsel yaklaşım özellikle çerçeve, kütüphaneler, sınıflar, bileşenler için geçerlidir, çünkü bu varlıklar projeler veya uygulamaların kurucu unsurları tarafından hizmet vermektedir. Bu, basit kullanılabilirlikleriyle ilgili büyük beklentiler olduğu anlamına gelir. Bu eserlerin tüketicisi anlamlarını mümkün olan en iyi şekilde geliştirmelidir. Minimal sürpriz ilkesi her zaman tonu vermelidir. Sonuçta, kimse ilk önce çalışma talimatlarını okuması gereken bir çekiç satın almak istemez. .NET veya JDK gibi çerçeve buradaki modeller arasındadır.
Bir soyutlamanın kalitesini objektif olarak değerlendirmek mümkün müdür? Sadece kısmen. Bununla birlikte, araçlar semantiği içermediği sürece bu değerlendirme otomatikleştirilemez. Peki ya öznel bir değerlendirme? Çalışır, ancak tanımlanmış bir uygulama bağlamında gerçekleşmelidir. Örneğin, anlaşılabilirlik ve tasarım yönetimi açısından.
Bu nedenle soyutlama, soyutlamaların uyumlu bir yapısına dahil edilmelidir. Ek olarak, soyutlamalar uygulamanın bağlamına kıyasla kendi kendine yetersiz olmalıdır. Soyutlama, bir hedef gruba iyi ve neredeyse kendiliğinden açılan deyimsel bir dilin temelidir.
()