Veri tabanı programlamasında depolamak istediğiniz verilere yaptığınız "normalizasyon" adı verilen bir teknik var.

Bu konsepti nesne tasarımına uygulamaya çalışan var mı? Nasıldın? Nasıl çalıştı?

Düzenleme: Genişletmek / netleştirmek için, veritabanı normalleştirme artıklığı azaltmak için bir dizi ilkeden daha fazlasıdır. İçinde bulunduğunuz adımlar ve aşamalar ve en azından hangi aşamada olduğunuzu gösteren orta derecede tarafsız önlemler var. Nesne tasarımının kendine has ilkeleri var ve koku kavramı var, ancak size söyleyebilecek benzer bir şey yapmanın bir yolu var mı? XX-form0,1,2 ... etc ... ve bir sonraki en "normalize" seviyeye geçme yöntemleriniz?

Veritabanının normalleşmesini sağlayan temel gerilimlerin bir kısmı bir OO sisteminde bulunmamakla birlikte, bazıları vardır. Bunlar, OO tasarım modellerine ve bazı şekillerde normalleşmeye benzeyen ilkelere yol açmıştır, en azından OO sistemleri ilişkisel veritabanlarına benzerdir. Örneğin:

• Tek Sorumluluk İlkesi
• Endişelerin Ayrılması
• Bir kez ve sadece bir kez , KURU

Başka bir deyişle, birisi veritabanı normalleştirme tekniklerini OOP'a uygulamaya çalıştı mı? Hayır, çünkü OOP zaten normalleşmenin ilişkisel veritabanları için çözdüğü ortak problemler için çözümlere sahiptir.

Evet, evet var

Bu konuda uzun süre sessiz kaldım; konuşmanın zamanı geldi.

• Bu konsepti nesne tasarımına uygulamaya çalışan var mı?

Evet. 20 yılı aşkın bir süredir nesne normalleşmesini (ve dolayısıyla altta yatan nesne yönelimli teorisi) resmileştirmeye çalışıyorum.

• Nasıldın?

Bu veri ve kodun farkına varmak suretiyle, en azından teoride, değiştirilebilir. Bu, normalleştirme ilkelerinin ve ilişkisel işlemlerin verinin yanı sıra kod için de geçerli olabileceği anlamına gelir.

• Nasıl çalıştı?

Şu ana kadar gayet iyi çalıştı: Kazandığım içgörüler, tasarımımın, analizimin ve yeniden yapılanma becerilerimin "gizli silahları" olduğuna inanıyorum.

Bundan önce halka açık bir şey söylemedim, çünkü sonunda araştırmayı bitirmek ve ima edilen araçları üretmek için zamanımın olacağına karar verdim - kendim.

Ancak, hayatımda devam eden her şeyin daha önemli, daha eğlenceli ve / veya daha karlı olduğu sonucuna vardım, araştırmayı bitirmek için zamanım olmayacak. Hiç. Ayrıca, sadece çalışmayı tamamlamak için gerekli CS teorik temeline sahip olmamamın önemli bir olasılığı var.

Yerel üniversitede, nedenini almak isterlerse bir doktora adayına ya da iki kişiye sponsorluk yapmayı sordum, ancak maalesef yerel üniversitemiz dilbilimsel programlama konusunda yeterli bir temel öğretmiyor.

Bu alanda bazı ilginç araştırmalar yapıldı, ancak bunların hepsi - farkında olduğum - işaretten az kaldı. Ya normalleşme ilişkisel bir arka plandan geldiği için nesne yönelimli modellere uygulanmadığını ya da normalleşmenin sadece nesneler tarafından tanımlanan verilere uygulandığını varsaydığını yanlış kabul eder. Ancak bazı çok yakınlarda kaçırılan bazı projeler var ...

Gerçekten ilginç olan şey, normale normalizasyon uyguladığınızda olur - iddia edeceğim , tüm yeniden düzenlemenin temelidir .

Şimdi, yapılacak en iyi şeyin, belki de DC'deki DevDays 2011'de konuşmayı isteyerek ve benim de bu kadar heyecanlı bir topluluk olup olmadığını öğrenmek isteyip istemediğimi düşünüyorum.

İşte bir gözetleme direği: Normalizasyon, minimal ve gereksiz bir şey yapma sürecidir. Bu nedenle nesne yönelimli programlamanın Kendinizi Tekrarlama (DRY) prensibi normalleşme hedeflerinin açık bir göstergesidir. Tüm iyi bilinen nesne yönelimli tasarım / programlama / yeniden düzenleme ilkelerinin nesne normalleşmesinin mantıksal sonucu olduğunu gösterebileceğime inanıyorum. Ayrıca, Nesnenin Normal Formunda (ONF) sistemlerle yapılabilecek, sadece yeniden yapılanmadan daha ilginç şeyler olduğunu da söyleyebilirim.

Bu Rein Henrichs'in mükemmel cevabı üzerine bir yorum olarak başladı , ama çok uzun sürdü ...

Normalleştirme ilişkisel verilere uygulanır. Her veriyi sadece bir yerde saklandığından veri bütünlüğünü sağlamayı kolaylaştıran çoğaltmayı önlemek için kullanılır. Normalleştirilmiş bir formun ihlallerini bularak ve düzelterek bir veritabanını normalleştirirsiniz.

Nesneye Yönelik Programlama veri üzerindeki işlemler için geçerlidir. Verileri birlikte işlemenin yollarını gruplamak içindir. Yinelenen yöntemleri elimine etmek için sınıflara benzer teknikler uygulayabilirsiniz, belki de işlemin hangi verileri yönettiğine veya bağlı olduğuna bakarak. Örneğin, OO perspektifindeki 1NF, bir sınıf içinde herhangi bir yinelenen işleme sahip olmaz. 3NF, yaygın olarak kullanılan kodun bir üst sınıfta olduğu iyi bir kalıtımsal yapıya karşılık gelebilir. Eminim burada bağımlılık enjeksiyonuna uygun bir yer bulabilirsin. İyi tasarım ilkeleri ve yeniden düzenleme ihlalleri bularak daha iyi bir tasarıma ulaşırsınız (normal formlar gibi henüz hiçbir şey keşfedilmemiş olsa da).

Her iki dünyada da iyi bir tasarıma ulaşmak için herhangi bir algoritmik yöntem yoktur. Rein Hendrichs'in belirttiği gibi, potansiyel sorunları tanımlayabilecek birçok prensip vardır (kod kokusu gibi). Tasarım desenleri ve en iyi uygulamalar, insanların kendilerine hitap etmeye çalıştığı yöntemlerden bazılarıdır. Test odaklı geliştirme, kodları harici olarak kullanacağınız gibi uygulayarak erken bulma girişiminde bulunur. Veri tabanı gelişiminde olduğu gibi, en iyi çözüm deneyim ve analiz ile bulunur.

Normalleşmeye benzeyen iş modeli nesnelerini tasarlamak için çok iyi bir yaklaşım , Renkli UML Modellemesidir .

Peter Coad tarafından bulunan ve iş modeli nesnelerinin soyutlanmasına yardımcı olan bir tasarım stratejisidir.

Ne yazık ki - UML ile Renkli Modelleme: Kurumsal Bileşenler ve Süreç - satıldı ve yalnızca kullanılmış olanları satın alabilirsiniz.

İnternet üzerinden bu teknik hakkında birkaç makale var.

İlişkisel tasarıma aşina iseniz, size rehberlik etmesi için Renkte UML Modellemeyi faydalı bulacaksınız:

• Peter Coad'ın 'Renkli Modellemesi' - Stephen R. Palmer'ın Notları

Sınıf diyagramınızı oluştururken kodunuzda ORM java ek açıklamalarını kullanmak için araştırma yaptınız mı? Hazırda Bekletme, modelleme aşaması tamamlandıktan sonra veritabanını oluşturur. Diyagram bu örnekte yalnızca kodun görüntüleyicisidir.

Nesne referansları veya işaretçiler yabancı anahtarlara benzer. Bu konuda düşünmeye istekli olduğum kadar derin. :)

Aslında daha derin düşüneceğim. Nesnelerinizi 0 veri yinelemeli olarak modellerseniz ve nesnelerinizi "sorgulayabilir" ve üzerlerinde set tabanlı güncellemeler gerçekleştirirseniz, bağlantı kesilmesi olmaz. Aslında bunu bir nesne tüketici kütüphanesi yaparak yapabilirsiniz. Microsoft bunu çoktan düşündü, ancak C # 'nın set-tabanlı LINQ sözdizimini "sorgu kitaplığı" üzerine koyma yönüne geçti.