Obiektowe rozterki, klasa opakowanie

Witam!
Na przykładzie: dao zwraca mi listę studentów, którą trzymam w pamięci w modelu i kilka obiektów będzie wykonywać na tym zbiorze różne operacje. Taka klasa opakowanie List<Encja> encje; Czy to jest dobra praktyka? Nic innego więcej to opakowanie nie robi mimo, że mogłabym tam trochę dodać, bo mam obiekty np. StudentInserter StudentRemover , które są wykorzystywane przez inne obiekty w modelu do dodawania / usuwania czegoś z tych opakowanych danych -> powiadamiają one kilka innych obiektów z modelu o tym, że coś zostało usunięte / dodanie, bo tamte obiekty tego wymagają.

np.

package model.StudentsBase;

import entity.Student;
import model.ChoosingStudents.StudentChooser;

public class StudentRemover {
	private StudentsBase studentsBase;
	private StudentChooser studentChooser;

	public void remove(Student student) {
		studentChooser.studentHasBeenRemoved();
		studentsBase.remove(student);
	}
	//settery i gettery .......

Sorry ale nic nie rozumiem :x
StudentRemover to cos w rodzaju observera?
Jesli nie, to moze taka konstrukcja by Ciebie zainteresowala (observer,observable).

StudentRemoverowi wstrzykuję StudentsBase . Obiekty modelu, które chcą np. usunąć z StudentsBase jakiegoś studenta korzystają przez studentRemovera.remove() , gdyż niektóre obiekty muszą być powiadomione o fakcie usunięcia i robi to StudentRemover (albo o fakcie dodania studenta -> to robi StudentInserter ). to wszystko (wszystkie obiekty o których mówię) tyczy się modelu i już załadowanego pewnego wycinka danych. Zastanawiam się czy klasa opakowująca List<Encja> encje; nie robiąca nic specjalnego jest okey. Mógłby wgl ktoś polecić jakieś książkę / materiały na temat OOP i prawidłowych podejść? Java Efektywne Programowanie i Clean Code?

Szczerze powiedziawszy nie mam pojecia co chcesz zrobic nawet po tych 2 postach... Ale na bank to podejscie gwalci KISS.

Problem jest ważny jeśli się próbuje robić DAO od początku i natrafia na problem słuchaczy.

1. Przede wszystkim warto znać Java Observable: http://docs.oracle.com/javase/7/docs/api/java/util/Observable.html

W Twoim przypadku zrobiłbym chyba coś takiego:

public class StudentModel extends Observable {
  private  StudentBase baza; // klasa DAO? 
  public void removeStudent(Student st) {     
     notifyObservers(new StudentModelEvent(smeBeforeDelete, st)); 
     baza.delete(st);
     notifyObservers(new StudentModelEvent(smeAfterDelete, st)); 
  }
  public void removeStudentList(List<Student> lst) {     
     notifyObservers(new StudentModelEventForList(smeBeforeDelete, lst)); 
     baza.delete(lst);
     notifyObservers(new StudentModelEventForList(smeAfterDelete, lst)); 
  }
};

StudentModelEvent to clasa opakowująca Enum + Student - może być po prostu

Pair<StudentModelEventCode, Student>

1. Po drugie książki:

"Rusz głową! Wzorce projektowe", Eric Freeman, Elisabeth Freeman, Bert Bates, Kathy Sierra - jest to łatwostrawne podejście do OOP. Książka gruba ale lekko się czyta.

Druga książka, trochę cięższa (chociaż mniej stron), którą każdy Pro Java Developer pewnie zna to "Wzorce Projektowe", Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.
Autorzy tej drugiej to tzw. "Gang of Four" - GoF i są uznawani za ojców "wzorców projektowych" - chociaż raczej ich nie wymyślili, po prostu spisali.
Ich strona domowa: http://hillside.net/the-gang-of-four

@vpiotr obserwator z javy (ten z pakietu java.util) jest kiepski. Wymaga wbicia się na chama w hierarchię klas, dziedziczenia i tego typu magii. Guava eventbus jest wygodniejszy, bo deklaratywny.

@karolinaa, to co chcesz osiągnąć to opakowana kolekcja, która udostepnia operacje na swoich obiektach, ale nie udostepnia obiektow jako takich. Dobrze rozumiem?

@Koziołek tak opakowana kolekcja, ale właśnie udostępnia swoje obiekty. W opakowaniu mam:

public Student get(int id) {
	return students.get(id);
}

Czy to dopuszczalne?
Te opakowanie to potem bean, który po prostu jest miejscem z danymi. Do tego obiekty modelu, które chcą dodać / usunąć jakieś dane z tego opakowania korzystają z dwóch obiektów ala-proxy:
StudentInserter - dodanie danych do opakowania wraz z powiadomieniem o tym fakcie innych obiektów modelu, które tego wymagają.
StudentRemover - analogicznie tylko usuwanie.

Mogłabym usunąć te dwa obiekty i po prostu dodać do opakowania Guava EventBusa i dwie klasy-zdarzenia, ale czy to w duchu single responsibility principle? Oprócz tego mam też kilka innych obiektów które korzystają z tych opakowanych danych (jest to springowy bean) i np. wyciągają obiekt get(int id) i modyfikują. Inny przykład - mam obiekt, który wybiera studenta do tego jest kilka strategi wyboru i nawet w implementacjach strategii tam też mam private StudentsBase studentsBase; (Ale to nie jest żadna baza tylko pewne dane w modelu, opakowana List<Encja> encje;).

nie wiem może wszystko jest dobrze a może wszystko źle. Kod wydaje mi się dość prosty,
jbc mogę wygenerować UML w Intellij IDEA i wrzucić jakby był kłopot ze zrozumieniem.

Ja bym osobiście z tego geta zrezygnował na tym poziomie. Względnie zrobił to na zasadzie jakiegoś getById, tak by to była naprawdę znacząca nazwa. Co do usuwania i dodawania - eventbus.
wrzuć tego UMLa