Obiektowa „normalizacja”

28

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?

Edward Strange
źródło
2
... Masz na myśli, że próbowaliśmy nie mieć wielu zbędnych zmiennych w naszych klasach i nie mieć wielu zbędnych klas w naszych projektach? Czy to w ogóle zadziała?
Satanicpuppy
2
@Steven A. Lowe: Gdzie byłeś pięć lat temu, kiedy decydowałem się na temat mojej pracy magisterskiej? ;)
Nigdy tego nie próbowałem (dlatego odpowiadam jako komentarz), ale zgaduję, że można to zrobić z pamięcią podręczną udostępnionych danych, wskaźnikami od obiektów do buforowanych danych udostępnionych i pewnego rodzaju mechanizmem wstrzykiwania zależności wskazać wskaźniki instancji na udostępnione dane ...
FrustratedWithFormsDesigner
Uważam to za bardzo interesujące pytanie.
5
Myślę, że refaktoryzacja obejmuje w zasadzie zarówno OOP, jak i inne metodologie programowania.
JohnFx

Odpowiedzi:

27

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.

Rein Henrichs
źródło
+1 Znacznie lepsze niż to, co próbowałem napisać!
Michael K,
To są zasady, a nie techniki. Jak wykorzystałbyś te zasady do „normalizacji” projektu obiektu?
Edward Strange
3
Normalizacja bazy danych jest również zasadą. W obu przypadkach istnieją wzorce (lub techniki) opisujące sposób podejmowania decyzji dotyczących tych zasad. Na przykład zajrzyj do książek Martina Fowlera na temat refaktoryzacji i książek Kent'a Beck o wzorach. Różnica polega na tym, że projekt bazy danych jest mniejszą, mniej złożoną domeną, która jest łatwiejsza do oszacowania i przekształcenia w prosty zestaw reguł.
Rein Henrichs
5
@Crazy Eddie: Jak to zrobić z relacyjną bazą danych? Poszukujesz przypadków naruszenia zasady i napraw ją. Jeśli zobaczysz klasę z trzema zadaniami, przepisujesz ją jako trzy klasy. Jeśli szukasz czasownika typu „normalizuj”, być może jego „refaktoryzator”, chociaż nie jest on tak konkretny, ale obejmuje.
Jeremy
1
@Rein: projekt bazy danych nie jest ani mniejszy, ani mniej złożony niż OOP, ale miał jedną wielką zaletę: zaczął od solidnych podstaw teoretycznych i modelu matematycznego. OOP ewoluowało wiele heurystyk, ale wciąż nie ma pełnego formalizmu.
Steven A. Lowe
18

Tak, tak mam

Długo milczałem na ten temat; czas się wypowiedzieć.

  • Czy ktoś próbował zastosować tę koncepcję do projektowania obiektów?

Tak. Od ponad 20 lat pracuję nad sformalizowaniem normalizacji obiektów (i stąd leżącej u podstaw teorii obiektowej).

  • Jak się masz

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.

  • Jak ci poszło?

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.

Steven A. Lowe
źródło
1
Jakieś bardziej istotne dokumenty?
Steve314,
4
PUBLIKOWAĆ! (proszę?) (ładnie proszę?) Jeśli potrzebujesz pomocy w uporządkowaniu dokumentów itp., skontaktuj się ze mną.
AJ01,
1
@ChrisCirefice: bądź szczęśliwy, napisz do mnie e-maila na [email protected]
Steven A. Lowe
1
@ChrisCirefice: doktorant FYI przeniósł się na inny uniwersytet; projekt na back-burnerze ponownie (ale piszę książkę o DDD)
Steven A. Lowe
1
Cześć @ StevenA.Lowe Jestem naprawdę zainteresowany twoimi badaniami. Znalazłem dość krótki artykuł encrypted.google.com/... czy masz na ten temat jakiś komentarz? BTW, może możesz zilustrować swój pomysł, pisząc najpierw post na blogu? Dzięki.
Wei Qiu
5

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.

Michael K.
źródło
2
Moim zdaniem zasady stanowią stwierdzenie o idealnym sposobie rozwiązania szeregu napięć. Wzory są heurystyczne dla stosowania zasady. Zasady IOW są stwierdzeniem o strukturze przestrzeni problemowej, a wzorce są zasadami przekształcania ich w przestrzeń rozwiązań. Ale jestem trochę matematykiem, więc myślę, że to dziwne :)
Rein Henrichs
2

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 :

Lucas Machado
źródło
0

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.

UML_GURU
źródło
0

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ń”.

jojo
źródło