Contratto di interfaccia, oggetto di classe?

Question

Il contratto si interfaccia come l'oggetto sta alla classe?

Qual è la necessità di differenziare cose identiche come questa, dal codice al codice in esecuzione? Ho avuto l'idea di nominare una classe una classe e la classe di esecuzione istanziata un oggetto, ma nel complesso, è l'unica ragione per questi termini semi-ridondanti?

Answer 1

Non proprio. Ci sono quattro termini qui, quindi esaminerò ciascuno di essi:

Interfaccia

Un'interfaccia è una classe astratta (in linguaggi come Java in cui non esiste ereditarietà multipla, a volte ci sono altre restrizioni, come un tipo di dati separato) che deve essere utilizzata come base comune per accedere a un numero simile -essere oggetti. Concettualmente, non vi è alcun requisito per l'astrattezza, ma di solito un'interfaccia avrà almeno un metodo astratto. Un'interfaccia è un metodo che consente al programma di comunicare con un numero di classi simili, ognuna con una semantica diversa ma con lo stesso scopo generale.

Contratto

Un contratto è l'accordo implicito che stipuli tra utenti e implementatori di una classe o interfaccia. Ad esempio, precondizioni e postcondizioni (gli invarianti sono di solito un contratto all'interno dell'implementazione della classe - in genere, non è necessario esporre cose come la relazione tra membri interni). Anche le specifiche per un valore di ritorno o un argomento possono far parte del contratto. Fondamentalmente rappresenta come utilizzare la funzione / classe / interfaccia e non è generalmente completamente rappresentabile in nessuna lingua (alcune lingue, come Eiffel, consentono di stipulare contratti espliciti, ma anche questi non possono sempre concretizzare pienamente i requisiti ). Quando si implementa un'interfaccia o si deriva da una classe, è sempre necessario soddisfare i requisiti dell'interfaccia o, quando si esegue l'override di una classe non astratta, comportarsi in modo abbastanza simile che un visualizzatore esterno non noti la differenza (questa è la Liskov Principio di sostituzione; un oggetto derivato dovrebbe essere in grado di sostituire la base senza alcuna differenza di comportamento dalla prospettiva esterna).

Class

Una lezione non ha bisogno di molte ripercussioni, dal momento che le hai chiaramente utilizzate in precedenza. Una classe è il tipo di dati e in alcune lingue è un superset di interfacce (che non hanno una definizione formale, come in C ++), e in altre è indipendente (come in Java).

Oggetto

Un oggetto è un'istanza di un tipo di classe (o di qualsiasi tipo non di classe, di solito). La definizione esatta di un oggetto è molto specifica per un linguaggio, ma la definizione generale è la cosa reale a cui fanno riferimento più riferimenti / puntatori alla stessa cosa - ad esempio, in alcuni linguaggi come Java, == confronta se due variabili sono stesso oggetto, non necessariamente se sono semanticamente uguali. Gli oggetti sono indipendenti da classi o interfacce: rappresentano una singola istanza. Un altro modo di pensarci è che la classe o l'interfaccia è lo stampo, e l'oggetto è l'oggetto fisico che esce dallo stampo (un'analogia piuttosto negativa, ma è la migliore che riesca a inventare in questo momento).

Answer 2

No, non proprio. Una classe è un modello che definisci. Ogni oggetto che crea un'istanza di quella classe segue il modello. Non sono termini veramente ridondanti, perché le due cose non sono identiche. Puoi pensare a una classe come a un tipo di dati definito dall'utente. Le classi e gli oggetti sono diversi l'uno dall'altro nello stesso identico modo in cui il tipo di dati primitivo int è diverso dal valore letterale 3.

Un'interfaccia definisce una serie di metodi che devono supportare tutte le classi di implementazione. L'interfaccia stessa è il contratto definito per le classi di implementazione. Dice solo che qualsiasi classe che implementa l'interfaccia deve avere l'insieme di metodi pubblici di tale interfaccia.

Answer 3

Beh, immagino ... se un'interfaccia specifica un contratto rispetto a una classe specifica un'istanza (o più) di uno specifico oggetto.

La terminologia è meno importante dell'applicazione comunque.

Answer 4

In realtà, un'interfaccia è un contratto, quando un oggetto è un'istanza di una classe: sono cose diverse che non hanno molto in comune.

L'interfaccia fornisce solo una facciata per gli oggetti o una garanzia per il chiamante che l'oggetto può eseguire alcune operazioni, anche senza sapere che è implementata.

Ad esempio, puoi avere due classi che implementano la stessa interfaccia / contratto, ma fanno cose totalmente diverse (anche se il significato di farle potrebbe essere lo stesso).

Prendi ad esempio l'interfaccia IDisposable: ogni oggetto può rilasciare le risorse che utilizza, ma può farlo in molti modi diversi, può scegliere di non rilasciare nulla. È la scelta dell'oggetto.

Almeno questo sarebbe il POV in .NET

Answer 5

Per completare le risposte precedenti, una parola sulle interfacce:

Se la classe è più di un modello per un oggetto (a causa delle sue caratteristiche globali indipendenti da qualsiasi istanza), l'interfaccia può anche essere descritta come punto di vista

Una classe che implementa diverse interfacce:

• completa il contratto che deve rispettare
• consente all'utente di vedere tutte le istanze di quella classe dal punto di vista di quello rappresentato dall'interfaccia implementata.

" Punto di vista " significa che puoi usare un oggetto concentrandoti esclusivamente sul contratto definito da quell'interfaccia.

È sotto questo aspetto che un'interfaccia è una "classe astratta", come in una "astrazione" (qualcosa che riprende alcune delle caratteristiche di una classe, ma ne lascia fuori altre). Nel mondo Java, un'interfaccia lascia davvero molto, dal momento che può essere applicata solo per definire il contratto, ad esempio, non per metodi o funzioni statici.

Answer 6

" Class " e " Oggetto " rappresentano due cose diverse; sono collegati, ma ciò che rappresentano È diverso, abbastanza fortemente.

Il modo migliore per descriverlo è guardare Statico. Una classe può avere membri statici, che sono completamente separati da qualsiasi ISTANZA di quella classe. Gli oggetti di quella classe possono o meno usare quei membri statici; ma l'istanza dell'oggetto di quella classe è completamente separata da qualsiasi uso statico di quella classe (o almeno dovrebbe essere).

O pensa al modello singleton. La memorizzazione di un'istanza dell'oggetto classe in un programma di accesso di classe statica è una pratica comune e mostra la differenza. Ti riferisci all'accessorio statico classe per ottenere la istanza di oggetto di una classe singleton; se il membro statico di classe non ha una istanza di oggetto a cui fare riferimento, la classe crea la istanza del oggetto .

In altre parole; un oggetto è un'istanza di una classe; ma una classe può essere più di un semplice modello da cui vengono istanziati gli oggetti. I membri statici delle classi hanno una rappresentazione in memoria completamente indipendente dalle istanze di oggetti di tali classi.