W programowaniu baz danych istnieje technika zwana „normalizacją”, którą wykonujesz w stosunku do danych, które chcesz przechowywać.
Czy ktoś próbował zastosować tę koncepcję do projektowania obiektów? Jak się masz Jak ci poszło?
Edycja: W celu rozszerzenia / wyjaśnienia normalizacja bazy danych jest czymś więcej niż zbiorem zasad ograniczających nadmiarowość. W rzeczywistości są kroki i etapy, przez które przechodzisz, i przynajmniej umiarkowanie obiektywne środki, które mówią ci, na jakim etapie jesteś. Projektowanie obiektów ma swoje własne zasady i istnieje koncepcja węchu, ale czy jest jakiś sposób na zrobienie czegoś podobnego, co powiedziałoby ci że jesteś w XX-formie 0,1,2 ... itd ... i metodach przejścia do następnego najbardziej „znormalizowanego” poziomu?
Odpowiedzi:
Chociaż niektóre z napięć leżących u podstaw normalizacji bazy danych nie występują w systemie operacyjnym, niektóre z nich są. Dały one początek wzorcom i zasadom projektowania OO, które są w pewnym sensie analogiczne do normalizacji, przynajmniej w takim stopniu, w jakim systemy OO są analogiczne do relacyjnych baz danych. Na przykład:
Innymi słowy, czy ktoś próbował zastosować techniki normalizacji bazy danych do OOP? Nie, ponieważ OOP ma już rozwiązania wspólnych problemów, które normalizacja rozwiązuje dla relacyjnych baz danych.
źródło
Tak, tak mam
Długo milczałem na ten temat; czas się wypowiedzieć.
Tak. Od ponad 20 lat pracuję nad sformalizowaniem normalizacji obiektów (i stąd leżącej u podstaw teorii obiektowej).
Uświadomienie sobie, że dane i kod są wymienne, przynajmniej w teorii. Oznacza to, że zasady normalizacji i operacje relacyjne mogą mieć zastosowanie zarówno do kodu, jak i danych.
Do tej pory działało całkiem nieźle - wierzę, że zdobyte spostrzeżenia były „tajną bronią” moich możliwości projektowania, analizy i refaktoryzacji.
Nie powiedziałem wcześniej o tym publicznie, ponieważ pomyślałem, że w końcu będę miał czas, aby dokończyć badania - i sam stworzyć implikowane narzędzia -.
Ale doszedłem do wniosku, że biorąc pod uwagę wszystko, co dzieje się w moim życiu, co jest ważniejsze, bardziej zabawne i / lub bardziej opłacalne, nie będę miał czasu, aby sam dokończyć badania. Zawsze. Istnieje również znacząca możliwość, że po prostu nie mam niezbędnych podstaw teoretycznych CS do samodzielnego ukończenia pracy.
Zapytałem na lokalnym uniwersytecie o sponsorowanie doktora lub dwóch doktorantów, czy chcieliby podjąć tę sprawę, ale niestety nasz lokalny uniwersytet nie uczy odpowiedniej podstawy w semantyce języka programowania.
Przeprowadzono kilka interesujących badań w tej dziedzinie, ale wszystko - o czym wiem - nie osiągnęło tego celu. Albo błędnie zakłada, że ponieważ normalizacja pochodzi z tła relacyjnego, nie ma ona zastosowania do modeli obiektowych lub zakłada, że normalizacja dotyczy tylko danych zdefiniowanych przez obiekty. Istnieje jednak kilka bardzo interesujących projektów typu miss-miss ...
Naprawdę ciekawe rzeczy dzieją się, gdy zastosujesz normalizację do kodu - co, jak twierdzę, jest podstawą całego refaktoryzacji .
Teraz myślę, że najlepszą rzeczą do zrobienia jest rozpowszechnianie wiadomości, być może poprzez poproszenie o przemówienie na DevDays 2011 w DC i sprawdzenie, czy istnieje społeczność tak podekscytowana takimi rzeczami jak ja.
Oto krótki wgląd: normalizacja to proces tworzenia czegoś minimalnego i niepotrzebnego. Zasada „programowania obiektowego” (Don't Repeat Yourself (DRY)) jest zatem wyraźnym przejawem celów normalizacji. Wierzę, że mogę pokazać, że wszystkie dobrze znane zorientowane obiektowo zasady projektowania / programowania / refaktoryzacji są logiczną konsekwencją normalizacji obiektu. Myślę, że mogę również pokazać, że istnieje więcej ciekawych rzeczy, które można zrobić z systemami w Object Normal Form (ONF) niż tylko refaktoryzacja.
źródło
Zaczęło się od komentarza na temat doskonałej odpowiedzi Reina Henricha , ale stało się za długie ...
Normalizacja dotyczy danych relacyjnych. Służy do uniknięcia powielania, co ułatwia integralność danych, ponieważ każdy układ odniesienia jest przechowywany tylko w jednym miejscu. Normalizujesz bazę danych, znajdując naruszenia znormalizowanej formy i je poprawiając.
Programowanie obiektowe dotyczy operacji na danych. Ma on na celu grupowanie sposobów manipulowania danymi. Możesz zastosować podobne techniki do klas, aby wyeliminować zduplikowane metody, być może patrząc na dane, którymi operuje operacja lub od których zależy. Na przykład 1NF w perspektywie OO nie miałby żadnych zduplikowanych operacji w klasie. 3NF może odpowiadać dobrej strukturze dziedziczenia, w której często używany kod należy do nadklasy. Jestem pewien, że możesz znaleźć również miejsce na zastrzyk uzależnienia. Osiągasz lepszy projekt (chociaż nie odkryto jeszcze niczego takiego jak normalne formy), znajdując naruszenia zasad dobrego projektowania i refaktoryzacji.
Tak naprawdę nie ma żadnych metod algorytmicznych, aby osiągnąć dobry projekt w żadnym ze światów. Jak zauważa Rein Hendrichs, istnieje wiele zasad, które mogą identyfikować potencjalne problemy (zwane także zapachami kodu). Wzorce projektowe i najlepsze praktyki to niektóre ze sposobów, w jakie ludzie próbowali się z nimi uporać. Programowanie oparte na testach próbuje je wcześnie znaleźć, ćwicząc kod, który będzie dostępny zewnętrznie. Podobnie jak w przypadku tworzenia baz danych, najlepsze rozwiązanie można znaleźć dzięki doświadczeniu i analizie.
źródło
Bardzo dobrym podejściem do projektowania obiektów modelu biznesowego, które jest podobne do normalizacji, jest modelowanie UML w kolorze .
Jest to strategia projektowania znaleziona przez Petera Coada, która pomaga wyodrębnić obiekty modelu biznesowego.
Niestety książka - Java Modeling In Color With UML: Enterprise Components and Process - jest wyprzedana i można kupić tylko używane.
W Internecie znajduje się kilka artykułów na temat tej techniki.
Jeśli znasz się na projektowaniu relacyjnym, przydatne będzie modelowanie UML w kolorze :
źródło
Czy badałeś użycie adnotacji Java ORM w kodzie podczas tworzenia diagramu klas? Hibernacja wygenerowałaby bazę danych po zakończeniu etapu modelowania. Schemat jest w tym przykładzie tylko przeglądarką kodu.
źródło
Odwołania do obiektu lub wskaźniki są podobne do kluczy obcych. To jest tak głębokie, jak tylko mogę o tym myśleć. :)
Właściwie zastanowię się głębiej. Jeśli modelujesz swoje obiekty z 0 duplikacją danych i możesz „zapytać” twoje obiekty i wykonać na nich aktualizacje oparte na zestawie, nie będzie rozłączenia. W rzeczywistości MOŻESZ to zrobić, tworząc obiektową bibliotekę konsumenta. Microsoft już o tym pomyślał, ale poszedł w kierunku uczynienia składni LINQ opartej na zestawie częścią C # w „bibliotece zapytań”.
źródło