Shakaz napisał(a):
Why interface is useful
Jak dla mnie najlepsze wytłumaczenie interfejsu.@marcin43210 Przeczytaj i powiedz, własnymi słowami, jak to rozumiesz.
Rozumiem to w taki sposób, że interfejs ułatwia pracę, pomaga, z nim jest dużo prościej i sprawniej, ale bez niego też się da coś zrobić (kosztem większego skomplikowania np).
...ale bez niego też się da coś zrobić (kosztem większego skomplikowania np).
Nawet nieobiektowo się da. Pytanie tylko po co?
@Shakazowi chodziło o to żebyś opisał własnymi słowami co to jest i jak działa interfejs.
@marcin43210 Czy Ty w ogóle przeczytałeś to, co Ci zalinkowałem?
ułatwia pracę, pomaga, z nim jest dużo prościej i sprawniej - taką definicję mogę podać do większości wykorzystywanych mechanizmów...
Super, rozumiesz już istotę interfejsów. Teraz, wykorzystując dziedziczenie oraz polimorfizm, masz kolekcję obiektów NapędzanyPojazd. Teraz w tej kolekcji możesz przechowywać rower, samochód, samolot, helikopter - bo przecież każdy z nich jest napędzany, prawda? Na tym przykładzie powiedz mi, jak w kodzie, za pomocą jakiegoś guzika START, wywołasz, aby każdy z 4 w.w. obiektów zaczął się poruszać? (pseudokod wystarczy)
Shakaz napisał(a):
Super, rozumiesz już istotę interfejsów. Teraz, wykorzystując dziedziczenie oraz polimorfizm, masz kolekcję obiektów
NapędzanyPojazd. Teraz w tej kolekcji możesz przechowywaćrower,samochód,samolot,helikopter- bo przecież każdy z nich jest napędzany prawda? Na tym przykładzie powiedz mi, jak w kodzie, za pomocą jakiegoś guzikaSTART, wywołasz, aby każdy z 4 w.w. obiektów zaczął się poruszać? (pseudokod wystarczy)
Więc tak:
Tworzę interfejs, np.:
public interface Start {
void goFaster();
}
Potem tworzę każdą z klas (samlot, samochód itd....), w której jest prędkość. Czyli np:
public class Car implements Start
{
int speed=0;
void goFaster()
{
speed+=10;
}
}
I tak każdą klasę, ale oczywiście w każdej z nich kod metody goFaster będzie inny.
Później tworzę ArrayList List<Start> napedzanyPojazd = new ArrayList<>(); i ją wypełniam tymi obiektami. I w tym momencię mogę po tej liście przejść wywołując na każdym elemencie metodę "goFaster". Czyli nie muszę się po kolei odwoływać do każdego obiektu.
@marcin43210 Brawo! Proste, nieprawdaż? :)
Interfejsy też pozwalają na zastosowanie abstrakcji w taki sposób, jak to opisał @Jaca777 w komentarzu wyżej. Masz pomysł, o co konkretnie może chodzić?
Shakaz napisał(a):
@marcin43210 Brawo! Proste, nieprawdaż? :)
Interfejsy też pozwalają na zastosowanie abstrakcji w taki sposób, jak to opisał @Jaca777 w komentarzu wyżej. Masz pomysł, o co konkretnie może chodzić?
No wlaśnie proste... ale najelpiej na takich właśnie przykłądach to zrozumieć. Wszędzie jest ogólny sens interfejsów, a przykładów, które w łopatologiczny sposób by pomogły je zrozumieć już tak dużo nie ma. Myślę, że wielu osobom ten temat pomoże:)
Co do postu kolegi jaca, to tak średnio rozumiem, co ma na myśli bo stwierdzenie typu "dodajesz to do konstruktora" nie mówi mi dużo. Co dodaje do konstruktora? Może jakiś przykład? Na pewno by mi wyjaśnił o co mu dokładnie chodzi:)
marcin43210 napisał(a):
No wlaśnie proste... ale najelpiej na takich właśnie przykłądach to zrozumieć. Wszędzie jest ogólny sens interfejsów, a przykładów, które w łopatologiczny sposób by pomogły je zrozumieć już tak dużo nie ma. Myślę, że wielu osobom ten temat pomoże:)
Nigdy w pełni nie zrozumiesz czegoś, dopóki nie przekonasz się na własnej skórze - czyli tworząc/modyfikując/czytając kod(tak, z czytania/przeglądania kodu idzie sporo się nauczyć).
Co do postu kolegi jaca, to tak średnio rozumiem, co ma na myśli bo stwierdzenie typu "dodajesz to do konstruktora" nie mówi mi dużo. Co dodaje do konstruktora? Może jakiś przykład? Na pewno by mi wyjaśnił o co mu dokładnie chodzi:)
Co może być argumentem w metodzie/konstruktorze?
Shakaz napisał(a):
marcin43210 napisał(a):
No wlaśnie proste... ale najelpiej na takich właśnie przykłądach to zrozumieć. Wszędzie jest ogólny sens interfejsów, a przykładów, które w łopatologiczny sposób by pomogły je zrozumieć już tak dużo nie ma. Myślę, że wielu osobom ten temat pomoże:)
Nigdy w pełni nie zrozumiesz czegoś, dopóki nie przekonasz się na własnej skórze - czyli tworząc/modyfikując/czytając kod(tak, z czytania/przeglądania kodu idzie sporo się nauczyć).
Co do postu kolegi jaca, to tak średnio rozumiem, co ma na myśli bo stwierdzenie typu "dodajesz to do konstruktora" nie mówi mi dużo. Co dodaje do konstruktora? Może jakiś przykład? Na pewno by mi wyjaśnił o co mu dokładnie chodzi:)
Co może być argumentem w metodzie/konstruktorze?
Co może być? No w zasadzie to wszytko. Każdy obiekt.
np. interfejs Repository pozwalający na zapis i odczyt danych + Jedyne co robisz, to przyjmujesz to jako argument metody czy konstruktora.
To na podstawie tego, stwórz sygnaturę metody save oraz read.
No właśnie, a ty nie chcesz każdego obiektu, chcesz tylko takie które mogą zrobić to co chcesz, czyli zapisywać dane do bazy/pliku.
Póki co to odpuszczam. Ważne, że ogarnałem sens i zastosowanie podstawowe interfejsów. To o czym teraz piszecie, to dla mnie czarna magia, nie wiem w ogole o co chodzi, dlatego na spokojnie powoli do tego dojdę za jakiś czas pewnie. Podaje interfejs jako argument i co dalej? Jak to ma się do tych zależności? Dla mnie jest ciężko zakumać cokolwiek bez przykładu. Sama teoria nic mi nie daje, muszę mieć coś pokazane w uzyciu. To tak jak z jazdą samochodem - wiesz, że musisz wbić bieg, puscic sprzęgło i dać gaz i wiesz za co każdy pedał odpowiada, ale musisz jednakl zobaczyć w praktyce jak to wygląa żeby zrozumieć i zacząć to stosować:)
W takim razie:
interface Repository {
void save(User user);
User get(String userName);
}
class FileRepository implements Repository {
@Override
public void save(User user) {
//Zapisywanie w pliku
}
@Override
public User get(String userName) {
//Odczyt z pliku i zwracanie
}
}
class MySQLRepository implements Repository {
@Override
public void save(User user) {
//zapis do bazy danych
}
@Override
public User get(String userName) {
// odczyt z bazy danych i zwracanie
}
}
class UserInterface {
private Repository repository;
public UserInterface(Repository repository) {
this.repository = repository;
}
public void showUser(String userName) {
User user = repository.get(userName);
//Wyświetlanie za pomocą dialogu
}
public String readAndSaveUser() {
User user = //Pokazanie dialogu i wczytanie danych
repository.save(user);
return user.getName();
}
}
public static void main(String... args) {
Repository repository = new FileRepository();
UserInterface userInterface = new UserInterface(repository);
String userName = userInterface.readAndSaveUser();
userInterface.showUser(userName);
}
Przeanalizuj ten kod i pomyśl co zmienić w nim, aby zapisywał użytkowników w bazie danych.
Ok, wieczorkiem sobie przeanalizuję krok po kroku :) Dzięki wszystkim za cierpliwość i pomoc bo dzięki Wam zacząłem to wreszcie trochę kumać:)
PS @Shalom @bogdans i inni moderatorzy - co Wy na to, aby w jakiś magiczny moderatorski sposób podpiąć, gdzieś ten temat, albo uwzględnić go w jakimś forumowym, javowym kompedium? Bądź, co bądź, całkiem nieźle zostały tutaj opisane interfejsy dla początkującego.
@marcin43210 nie czytałem całego wątku i nie wiem czy to zostało poruszone ale interfejs można fajnie wytłumaczyć na przykładzie filter pattern
nie mam czasu pisać example, ale ogólnie chodzi o to że masz np interfejs Filter z metodą filter() i robisz np 3 implementacje: StartsWithUppercaseFilter, ContainsALetterFilter i ContainsNumberFilter (wiem, że przykłady troche z d*!@ :D).
Z racji, żę każda z nich implementuje Filter to mozesz zrobić np kolekcje(ArrayList np) filtrów i za ich pomocą filtrować jakiś string, obiekt, whatever :) filtr tylko zwroci true/false czy walidacja się udała
Gdybyś nie miał interfejsu to nie mógłbyś zrobić tego "zestawu filtrów" którymi dane słowo/obiekt filtrujesz. (no mógłbyś zrobić Object ale.. :D)
Sorry za złotego szpadla, ale to najlepszy zbiór informacji o interfejsach na tym forum, nie chciałem otwierać nowego. Skoro każdy już wie, czym jest interfejs, to może ktoś napisać, kiedy stosować interfejs a kiedy klasę abstrakcyjną? Jak dla mnie teraz, skoro interfejsy mogą mieć metodę defaultową, to chyba klasy abstrakcyjne są zbędne, ale chętnie posłucham kogoś mądrzejszego.
Klasa abstrakcyjna ma:
Ale tak czy siak, to nie znaczy, że nalezy używać. Nnajlepiej używać najmniejszej konstrukcji spełniającej wymagania. (least power).
Klasa abstrakcyjna może dziedziczyć po innej klasie, może mieć pola, metody które na tych polach operują. Metoda oznaczona jako abstrakcyjna nie musi być koniecznie publiczna. Jest to też oczywisty sposób wskazania jak rozszerzać klasę.
public abstract class NullSafeMap<K, V> extends HashMap<K, V>
{
@Override
public V get(Object key)
{
V value = super.get(key);
if (value != null)
{
return value;
}
@SuppressWarnings("unchecked")
K typedKey = (K)key;
V createdValue = createValue(typedKey);
put(typedKey, createdValue);
return createdValue;
}
protected abstract V createValue(K key);
}