Owszem, ale o ile w Twoim akademickim przykładzie wyodrębnianie Engine, który ma wiele swoich atrybutów z Car może mieć jeszcze jakiś sens, to robienie oddzielnej encji na raptem dwie daty już niekoniecznie.
Popatrz jednak na to z innej strony.
Dwie daty mogą być ze sobą związane na wiele sposobów. Można z nich wyciągnąć różnicę dat (w jakiejkolwiek postaci).
W takiej klasie może powstać około 5 funkcji. Gdybym tego nie wyodrębnił to musiałbym pisać te 5 funkcji w każdej klasie mającej 2 daty.
(dziedziczenie tu nie wchodzi w grę, gdyż klasy już dziedziczą po innych klasach)
W takim razie rozpatrzmy taki przypadek:
Tworzymy sobie dwa Taski: "posprzątać pokój" i "naprawić samochód", obu przypisujesz ten sam obiekt DataRange z StartDate=2012-09-12 i EndDate=2012-09-15. Zatem dwa obiekty Task współdzielą jeden obiekt DataRange, jest fajnie.
Niestety, okazuje się, że sprzątanie pokoju trwa jednak dłużej niż naprawa samochodu i trzeba przestawić datę końcową na 2012-09-17. Przestawiamy ją dla zadania "sprzątanie pokoju" i co się dzieje? "naprawa samochodu" też ma zmienioną datę! Absurd, trzeba to poprawić. Jak? Tworząc nowy obiekt DataRange i ustawiając mu inne daty.
W efekcie są dwa Taski i dwa powiązane z nimi DataRange, nie ma żadnego współdzielenia jest za to bardziej skomplikowana logika edycji dat... I po co tak?
To nie tak ma działać.
Tworzymy sobie taska:
Posprzątać pokój. Tworzymy go i przypisujemy wartości między innymi dwie daty.
Task ClearRoom = new Task();
ClearRoom.SetTask("Posprzątać pokój");
ClearRoom.SetDateRange(new DateTime(1, 1, 2012), new DateTime(2, 1, 2012));
następnie tworzymy taska "naprawić samochód":
Task RepairCar = new Task();
RepairCar.SetTask("Naprawić samochód");
RepairCar.SetDateRange(new DateTime(1, 1, 2012), new DateTime(2, 1, 2012));
UWAGA:
Jak widzicie zrezygnowałem z konstruktora mającego parametry. To ze względu na to, że każde zadanie można grupować oraz podawać informacje dodatkowe (zastosowałem dziedziczenie), więc konstruktor i tak byłby duży i zamiast tego tworzę 3-4 funkcje ustawiające określone dane.
Teraz modyfikując np "Naprawić samochód" wystarczy zrobić:
RepairCar.SetDateRange([...])
i po sprawie.
Tak to ma działać.
Wyodrębniłem pewne informacje w celu napisania kodu specjalnie dla tych dat. (wspominanych wcześniej funkcji różnic dat)
Niby dlaczego osobne? Napisałbym jedną i nie miałbym N poprawek dla N klas. (O ile oczywiście byłoby to potrzebne, bo w tym przypadku nie bardzo, typy datowe udostępnia chyba każdy język.)
Nie mógłbyś napisać jednej, bo klasy by nie mogły po tym dziedziczyć. Już dziedziczą po innej klasie odpowiadającej za posiadanie grupy i informacji.
W rezultacie miałbyś:
Class Note
{
[...]
DateTime Create;
DateTime Edit;
[Funkcje dla dat]
}
Class Task
{
[...]
DateTime Start;
DateTime Stop;
[Te sam efunkcje dla dat]
}
No chyba, że da się te funkcje wydzielić jakoś :)?
To dobrze, że przejmujesz się projektowaniem aplikacji, wiele osób tego nie robi. Ale Ty aż za bardzo chcesz to dzielić i kombinować
Wiem, że strasznie kombinuję. :)
I wiem, że wymyślam różne dziwactwa, ale... o to mi właśnie chodzi. Już kiedyś napisałem taki program właśnie bez dzielenia szczególnego itp., teraz zaś chciałbym spróbować napisać inaczej - łatwiej / ładniej.
Stąd moje długie przemyślenia na temat projektu i tego jak to ma ze sobą wszystko działać.