W dobrej zasadzie OOP, powinien nodeView prosić o dodanie do drzewa, lub czy drzewo dodać nodeView?

Question

Zastanawiam się, co jest dobrą zasadą OOP, jeśli w aplikacji na iOS, jest UITreeView, a UINodeView z przedmiotem UITreeView o rootNodeView i węzeł ten korzeń odgałęzia z leftChildNodeView i rightChildNodeView.

Jeśli każdy obiekt UINodeView może być "przeciągnięty i upuszczony", to gdzie na ekranie, który jest implementowany w obsłudze UINodeView '-touchesMoved, jest ta dobra zasada OOP? Ponadto, jeśli nowy nodeView foo jest naprawdę bliski jednemu z węzłów, który nie ma lewego lub prawego potomka, węzeł foo można dodać do tego węzła jako element podrzędny.

I przypuszczam, że jeśli kolejny nodeView jest bar a także nie ma rodziców (czyli także zwisające), ma sens, że foo mogą być dodawane jako dziecko bar „s, jak również.

Gdyby ten foo nodeView „prosić o pozwolenie od węzła do dodania jako lewe lub prawe dziecko” i „go dodać jeśli dozwolone”, lub jeśli w UIViewController lub UITreeView wykryje, że węzeł porusza się wewnątrz siebie, a " zdecydować, że jest on zbliżony do innego węzła (wszystkich węzłów na ekranie) i nie ma lewego lub prawego dziecka i dodać foo jako dziecko "?

Oczywiście jeśli tylko węzeł w drzewie można dodać węzeł podrzędny, wówczas UITreeView może wykonać zadanie, ale jeśli dowolnego węzła (zwisające lub nie) może być rodzic, następnie UIViewController lub główny widok UIView wydaje się potrzeba wykonać tę pracę.

Czy robi to w taki czy inny sposób naruszając dobre zasady OOP?

Answer 1

Powiedziałbym, że UITreeView powinien sobie z tym poradzić, a węzły powinny poinformować go poprzez protokół/delegata-komunikację o zmianach pozycji. TreeView jest jedynym obiektem, który może sprawdzić, czy zmiana pozycji węzła powoduje kolizję z innym węzłem itp.

Jeśli chcesz napisać naprawdę dobry kod OOP, spróbuj użyć "kontrolera widoku modelu" -pattern, gdzie twój Widok to Twój TreeView, twój Model powinien przechowywać wszystkie Node-Dane-Obiekty i zapewnić pewne metody wykrywania kolizji między węzłami, a twój Kontroler powinien otrzymać zmiany pozycji z twojego widoku, porozmawiać z modelem, zdecydować co wykonać, a następnie podjąć odpowiednie działania (takie jak dodanie węzła jako liścia innego węzła).

Dzięki temu możesz w pełni dostosować się do przyszłych zmian, takich jak wykorzystanie bazy danych zamiast pamięci RAM do przechowywania danych lub użycie kodu dla iPada zamiast iPhone'a po prostu przez zastąpienie widoku.

Answer 2

Zgadzam się ze STK, musi istnieć wyraźne rozróżnienie między modelem, czyli implementacja reguł biznesowych, a widokiem (widokami), które są wizualną reprezentacją.

Akapit odkrywcze jest ostatni:

Oczywiście jeśli tylko węzeł w drzewie można dodać węzeł podrzędny, wówczas UITreeView może wykonać zadanie, ale jeśli dowolnego węzła (zwisające lub nie) może być rodzicem , następnie UIViewController lub główny widok UIView wydaje się potrzebny do wykonania zadania .

Innymi słowy, Twój model zależy od reguł biznesowych.Musisz zaprojektować logikę, aby móc wyrażać reguły. Jeśli masz swobodnie pływające węzły, to wyraźnie muszą one trzymać logikę załączników.

W ten sposób oddzielić logikę drzewa/węzła od logiki widoku.