[JAVA] Implementen van een Interface d.m.v. reflection?

[Verwijderd]

Is dit mogelijk?

Ik kan door middel van:

code:

Object eenInstantieVanEenClass = eenClassObject.newInstance()

... wél een object intstantiaten...

Maar een interface moet ik implementen d.m.v. het implements keyword achter de naam van de class (die een interface wil implementen).

Maar het type van die Interface is dus nog niet bekend...

Na een search zag ik al iets voorbij komen dat een instantie van een Interface echter nog niet bekend hoeft te zijn (het blijft in feite een class).

Maar hoe associeer ik mijn huidige class-instantie dan met die Interface-instantie?

[Macros]

Interfaces hebben geen code, dus als je daar zomaar een instantie van maakt zou er geen code zijn om uit te voeren. Als je zomaar een object instantieerd, die wel die interface implementeerd kan je hem daarna wel casten naar dat(/die?) interface.
Bedoel je dat?

[Verwijderd]

Maar het type van die Interface is dus nog niet bekend...

Dus: ik heb een Object (this gelukkig...) en ik wil dat een Interface laten implementen waarvan ik (officieel) het type niet ken.

Klinkt gek, want waarom zou ik die dan willen implementen , maar ik moet al m'n imports laden door middel van een classloader...
Maar ik weet dus wel welke Interface ik wil implementen en waarom, laat daar geen misverstand over bestaan. Helaas weet Java dat dus niet...

Voor dat dit uitdraait op een discussie over mijn methode: is dat mogelijk ja of nee (als iemand het kan zeggen)?

Zo nee, dan is het een serieus gebrek wat mij betreft, want dan kun je minder met reflection dan met de klassieke en gebruikelijke OOP-methode.

Dat was sowieso een spanningsveld maar goed.

Er zitten in de reflection API wel diverse methoden om met Interfaces te werken. Helaas kan ik nergens voorbeelden vinden die verder gaan dan het enumeraten van de Interfaces die reeds worden geimplementeerd door een of andere instantie van een class...

Maar daar heb ik dus weinig aan.

[Macros]

Maar hoe wil je nu een interface instantieren? Dat kan toch niet. Je kan alleen objecten instantieren, en die kunnen dan je interface implementeren.
Aspects kunnen wel bestaande klassen interfaces laten implementeren, maar ik weet niet hoe sterk de mogelijkheden voor reflectie zijn. Zoek dan even naar AspectJ.

[PommeFritz]

Heb je hier iets aan? dynamic proxy

[Verwijderd]

Ik wil geen Interface instantiaten, maar er werd ergens zoiets geopperd in een topic dat ik vond een zoektocht op GoT.

Ik zal eens naar AspectJ kijken, maar volgens mij is dat (weer) een third-party library en daar heb ik weinig zin, heb al genoeg problemen met die imports...

edit:
Wat ik wel wil lijkt me vrij duidelijk, ga af op mijn één na laatste post op dit moment.

edit2:
Dat waarnaar de vorige spreker refereert lijkt er meer op. Maar het wordt wel weer nodeloos ingewikkeld, maar goed dat haal ik mezelf op de hals.
Ik zal mijn design maar eens heroverwegen...

[ Voor 37% gewijzigd door Verwijderd op 13-06-2004 19:35 ]

[Robtimus]

Als je al weet welke interface je class implementeert, dan declareer je dat toch gewoon zo?

Java:

public class SomeClass implements SomeInterface

Volgens mij begrijp ik je totaal niet. Is reflection hier wel nodig? Want reflection is alleen maar nodig als je niet weet welke class iets is, bv omdat die class door de user wordt opgegeven.

Verder kun je een class overal gewoon gebruiken waar een implementatie van een interface is vereist, zoals een List.

[Macros]

Na een search zag ik al iets voorbij komen dat een instantie van een Interface echter nog niet bekend hoeft te zijn (het blijft in feite een class).

Volgens mij duide dat dan op anonymous classes. Dat ziet er zo uit:

Java:

InterfaceNaam instantie = new InterfaceNaam(){
    public Object methodeNaam(Object obj){
        return obj;
    }
};

[Verwijderd]

IceManX schreef op 13 juni 2004 @ 19:34:
Als je al weet welke interface je class implementeert, dan declareer je dat toch gewoon zo?

Java:

public class SomeClass implements SomeInterface

Ik zeg juist dat Java (de JVM om meer precies te zijn) dat dus nog niet weet compile-time.

Volgens mij begrijp ik je totaal niet. Is reflection hier wel nodig? Want reflection is alleen maar nodig als je niet weet welke class iets is, bv omdat die class door de user wordt opgegeven.

Dat weet de JVM dus niet, maar ik wel.

Verder kun je een class overal gewoon gebruiken waar een implementatie van een interface is vereist, zoals een List.

Bedoel je een class of een Class-object. Is een belangrijk detail.

[Verwijderd]

Macros schreef op 13 juni 2004 @ 19:36:
[...]

Volgens mij duide dat dan op anonymous classes. Dat ziet er zo uit:

Java:

InterfaceNaam instantie = new InterfaceNaam(){
    public Object methodeNaam(Object obj){
        return obj;
    }
};

OK. En waar tover ik die InterfaceNaam vandaan?

[Macros]

Ik zei niet dat dit je oplossing was
Maar ik denk dat hier je oplossing staat:
http://java.sun.com/j2se/...a/lang/reflect/Proxy.html

PS. Die proxies heb ik 1 keer mee gewerkt. Ik kon er toen niet echt een nuttige applicatie voor vinden en ik vond het erg onduidelijk en lastig

[ Voor 34% gewijzigd door Macros op 13-06-2004 19:43 ]

[Verwijderd]

Idd, dat zei PommeFritz ook al dus mijn reactie is ook op jou van toepassing.

Maar is nogal nasty als je niet weet hoe men dit oplost in Java en je dus maar uit moet komen op een Proxy als het opgeven van een aantal sleutelwoorden in Google je niet verder helpt....

[Robtimus]

Verwijderd schreef op 13 juni 2004 @ 19:38:
[...]

Ik zeg juist dat Java (de JVM om meer precies te zijn) dat dus nog niet weet compile-time.

Let me get this straigt.
Jij kent SomeClass. Jij schrijft SomeClass zelfs.
Jij kent SomeInterface.

Waarom zou de JVM SomeInterface compile-time niet kennen? Is deze wel geimporteerd? Zit de class file wel in je classpath? Of wat is anders de reden?


Verder betwijfel ik of anonieme classes wel mogelijk zijn met reflection.

* Robtimus begint het totaal niet meer te snappen

[Verwijderd]

IceManX schreef op 13 juni 2004 @ 19:47:
[...]
Let me get this straigt.
Jij kent SomeClass. Jij schrijft SomeClass zelfs.
Jij kent SomeInterface.

Waarom zou de JVM SomeInterface compile-time niet kennen? Is deze wel geimporteerd? Zit de class file wel in je classpath? Of wat is anders de reden?

Die reden heb ik al gegeven. Ik laad al mijn libraries met een classloader, vanwege beperkingen aan de manifest-file in het jar-archief i.c.m. Ant.

Verder betwijfel ik of anonieme classes wel mogelijk zijn met reflection.

/me begint het totaal niet meer te snappen

Is wel mogelijk maar schijnen wat haken en ogen aan te zitten. Maar dat is offtopic

[misfire]

Volgens mij weet je niet wat het begrip interface inhoudt. Je duidt hier op een beperking van Java, maar volgens OOP is het "een object is een instantie van een klasse". Een klasse kan de interface implementeren. Je kunt dus geen instantie van een interface hebben. Dit zijn gewoon OO spelregels en heeft niets te maken met een beperking van Java.

Je kunt wel een instantie van _een_ klasse hebben die een interface implementeert, waarbij je at compile time niet hoeft te weten wat die klasse is. De enige requirement voor de runtime is dan dat de interface door de klasse geimplementeerd wordt. Dat kun je wel bereiken met reflectie.

Het implementeren van een interface dmv reflection is niet mogelijk. Je kunt _alleen_ een interface implementeren door een klasse hiervoor op te stellen of aan te passen. In Java zijn er verschillende manieren om dit te doen, oa met dynamische proxies, anonieme klasses en runtime bytecode generatie (eventueel dmv AOP). Reflectie is _alleen_ het uitlezen van type informatie en het runtime invoken van operaties, dat is dus een totaal ander mechanisme.

Je geeft zelf aan dat je met classloaders aan het goochelen bent, dus ik neem dat je at runtime wil dat klasses een bepaalde interface gaan implementeren. Je kunt hiervoor kijken naar Javassist, hiermee kun je vrij comfortabel runtime bytecode modificatie doen.

Ik zou echter je aan willen raden om eerst je te verdiepen in de OO principes over klasses, objecten, interfaces en types, en in de Java mechanismes als reflectie, classloaders, type namespaces en code access/vm security. De volgende keer zou je je topic titel wat beter kunnen formuleren, en ook in minder dan anderhalve zin kunnen zeggen wat je probleem is, wat je al geprobeerd hebt, en wat je nu wilt bereiken.

[Verwijderd]

misfire schreef op 13 juni 2004 @ 20:06:
Volgens mij weet je niet wat het begrip interface inhoudt. Je duidt hier op een beperking van Java, maar volgens OOP is het "een object is een instantie van een klasse". Een klasse kan de interface implementeren. Je kunt dus geen instantie van een interface hebben. Dit zijn gewoon OO spelregels en heeft niets te maken met een beperking van Java.

Dat beweer ik ook niet, dat kwam ik (nogmaals) tegen tijdens een search.
Verder is een Interface niets meer dan een vorm van een abstract class.

Je kunt wel een instantie van _een_ klasse hebben die een interface implementeert, waarbij je at compile time niet hoeft te weten wat die klasse is. De enige requirement voor de runtime is dan dat de interface door de klasse geimplementeerd wordt. Dat kun je wel bereiken met reflectie.

Oftewel, dan moet je de Interface kennen als jijzelf die bewuste Interface wil implementen.

Ik heb het dus niet over een (onbekende) class, die achter de schermen zelf al een Interface implement.

Het implementeren van een interface dmv reflection is niet mogelijk.

Als ik die Proxy javadocs bekijk zie ik toch wat anders...

Je kunt _alleen_ een interface implementeren door een klasse hiervoor op te stellen of aan te passen. In Java zijn er verschillende manieren om dit te doen, oa met dynamische proxies, anonieme klasses en runtime bytecode generatie (eventueel dmv AOP). Reflectie is _alleen_ het uitlezen van type informatie en het runtime invoken van operaties, dat is dus een totaal ander mechanisme.

In het geval van dynamische proxies is dat toch hetzelfde als waar je zojuist van zegt dat het onmogelijk is?

Je geeft zelf aan dat je met classloaders aan het goochelen bent, dus ik neem dat je at runtime wil dat klasses een bepaalde interface gaan implementeren. Je kunt hiervoor kijken naar Javassist, hiermee kun je vrij comfortabel runtime bytecode modificatie doen.

Dat is wel weer heel draconisch...
Maar zoals ik al zei heb ik m'n design reeds aangepast.

Ik zou echter je aan willen raden om eerst je te verdiepen in de OO principes over klasses, objecten, interfaces en types, en in de Java mechanismes als reflectie, classloaders, type namespaces en code access/vm security. De volgende keer zou je je topic titel wat beter kunnen formuleren, en ook in minder dan anderhalve zin kunnen zeggen wat je probleem is, wat je al geprobeerd hebt, en wat je nu wilt bereiken.

De topictitel is duidelijk genoeg, en beschrijft precies wat ik wil. Als dat niet mogelijk zou zijn, betekent dat nog niet dat mijn topictitel fout is.
Wat mijn probleem is zeg ik al.
Wat ik al heb geprobeerd staat er al, maar qua code viel er niet veel te proberen want ik kon niks vinden...
Wat ik wil bereiken lijkt me vrij voor de hand liggend, mijn eerder beschreven probleem oplossen.

[misfire]

Verwijderd schreef op 13 juni 2004 @ 20:19:
Dat beweer ik ook niet, dat kwam ik (nogmaals) tegen tijdens een search.
Verder is een Interface niets meer dan een vorm van een abstract class.

Je beweert wel degelijk dat Java verkeerd met allerlei begrippen om zou gaan. Een interface is dus niet een abstract class. Het zijn echt aparte dingen. Doe eens een Java cursus of lees een goed boek zou ik zeggen.

Oftewel, dan moet je de Interface kennen als jijzelf die bewuste Interface wil implementen.

Ik heb het dus niet over een (onbekende) class, die achter de schermen zelf al een Interface implement.

Natuurlijk moet je de interface kennen. Wat heb je aan een interface als je er niks van weet?

Als ik die Proxy javadocs bekijk zie ik toch wat anders... In het geval van dynamische proxies is dat toch hetzelfde als waar je zojuist van zegt dat het onmogelijk is?

Weet je wel wat die Proxy klasse doet? Runtime invokaties delegeren op basis van bekende interfaces naar andere objecten (namelijk een object dat de InvocationHandler interface implementeert). Met de proxy klasse kun je geen bytecode modificatie doen, en ook geen klasses een interface laten implementeren oid. Als je vervolgens oplossingen waarmee het wel kan te draconisch vindt dan kan ik daar ook niets aan doen.

De topictitel is duidelijk genoeg, en beschrijft precies wat ik wil. Als dat niet mogelijk zou zijn, betekent dat nog niet dat mijn topictitel fout is.

Je topic start geeft aan dat je niet weet wat het verschil is tussen een interface en een klasse en dat je niet weet wat reflectie is.

Wat mijn probleem is zeg ik al.

Waarom dat je dit allemaal wilt doen leg je niet uit, dus je probleem is niet bekend. Een probleem is altijd functioneel, nooit technisch. Als jij niet uitlegt waarom jij dit allemaal wilt doen weten wij de context van je vraag niet en kunnen we ook geen alternatieven geven.

Het helpt ook niet om na een inhoudelijke reactie meteen te gaan schieten op het verhaal met allerlei bijdehande opmerkingen en niet verder in te gaan op de vragen. Er is door verschillende mensen hier al gevraagd wtf je eigenlijk wilt maken, dus blijkbaar het ligt niet aan mij, maar aan jou. Lees je maar eens in in de onderwerpen die ik aanhaalde, dan kun je je in het vervolg beter uitdrukken in algemeen begrepen technisch jargon als je weer met een problem zijn.

[Verwijderd]

misfire schreef op 13 juni 2004 @ 20:41:
[...]

Je beweert wel degelijk dat Java verkeerd met allerlei begrippen om zou gaan.

Indien...

Een interface is dus niet een abstract class. Het zijn echt aparte dingen. Doe eens een Java cursus of lees een goed boek zou ik zeggen.

Ik zeg niet dat ze hetzelfde zijn, ze lijken erg op elkaar.

http://mindprod.com/jgloss/interfacevsabstract.html

[...]
Natuurlijk moet je de interface kennen. Wat heb je aan een interface als je er niks van weet?

Wat ik weet hoeft de JVM niet te weten, als ik niets kan importen. Lees het topic eens, zou ik zeggen.

[...]
Weet je wel wat die Proxy klasse doet? Runtime invokaties delegeren op basis van bekende interfaces naar andere objecten (namelijk een object dat de InvocationHandler interface implementeert). Met de proxy klasse kun je geen bytecode modificatie doen, en ook geen klasses een interface laten implementeren oid. Als je vervolgens oplossingen waarmee het wel kan te draconisch vindt dan kan ik daar ook niets aan doen.

Dat is voor mijn probleem ook nuttig. Maar helaas komen die runtime invocations niet voor als geen enkele class die onbekende Interface implement. Dus dan werkt het inderdaad niet. Zoals ik al zei zou ik hier verder naar kijken, je kunt niet van mij verwachten dat ik alle suggesties binnen enkele minuten volledig begrijp.
Maar bedankt voor je bijdrage, dan is dat ook weer duidelijk.
Maar waarom kan dit dan niet?
Waarom kun je niet runtime bepaalde objecten een Interface laten implementeren die je hebt achterhaald door middel van de reflection API?
Als daar een reden voor is heb ik niets gezegd, dus vat het niet op als een klacht oid zonder dat ik weet waar ik het over heb.

Ik heb het nooit over bytecode modificaties gehad.

[...]

Je topic start geeft aan dat je niet weet wat het verschil is tussen een interface en een klasse en dat je niet weet wat reflectie is.

Ik heb een vraag, ik geef geen lezing.
Jij weet zelf wel wat het verschil is, en ik zie niet in hoe wat jij zegt uit mijn start post zou blijken.

[...]

Waarom dat je dit allemaal wilt doen leg je niet uit, dus je probleem is niet bekend. Een probleem is altijd functioneel, nooit technisch. Als jij niet uitlegt waarom jij dit allemaal wilt doen weten wij de context van je vraag niet en kunnen we ook geen alternatieven geven.

Ik vraag ook niet om alternatieven, ik heb een (technische) vraag. De reden dat ik dit doe is dat ik ellenlange discussies over de methode die ik hanteer wil vermijden.
Want die zie ik nogal vaak hier en zijn best leuk als hobby maar daar heb ik momenteel geen tijd voor...

Het helpt ook niet om na een inhoudelijke reactie meteen te gaan schieten op het verhaal met allerlei bijdehande opmerkingen en niet verder in te gaan op de vragen.

Jij loopt juist bijdehand te doen, en dat stel ik niet echt op prijs. Ik ga niet in op vragen als ik een reden heb om het nut van de vragen te betwijfelen, en die beschijf ik in mijn 'bijdehante' opmerkingen.

Er is door verschillende mensen hier al gevraagd wtf je eigenlijk wilt maken, dus blijkbaar het ligt niet aan mij, maar aan jou.

Dat is een kromme gevolgtrekking, één persoon begreep het niet echt, maar 2 hebben mij nu al het antwoord gegeven. De vraag is ook niet wat ik wil maken, de vraag is of iets kan ja of nee. Als daar verdere vragen uit volgen kun je van mij op aan dat ik ze hier zal posten hoor.

Lees je maar eens in in de onderwerpen die ik aanhaalde, dan kun je je in het vervolg beter uitdrukken in algemeen begrepen technisch jargon als je weer met een problem zijn.

Ik druk me prima uit en ik vind het belerend overkomen als je anderen minachtend opdraagt om zich meer in te lezen.

[Verwijderd]

Ik houd er over op, ik ben maar een simpele student en heb nog niet jouw inzicht in Java Misfire.
Dus als ik laks overkwam dan was dat onbedoeld.
Het is dat ik het moet leren, maar ik ben meer een aanhanger van functionele talen...

Als je nog weet waarom Sun voor die beperking heeft gekozen hoor ik het natuurlijk graag, maar laten we nou niet gaan zitten discussieren want zo zal niemand meer hier vragen gaan stellen.
_{Is dat slecht?}

[thijsc]

Bedoel je niet gewoon zoiets eigenlijk:

Java:

Object obj = myClass.newInstance();

MyInterface mi;
if ( obj instanceof MyInterface ) {
    mi = (MyInterface) obj;
} else {
    mi = null;
}

Je maakt een object aan, kijkt of het object een bepaalde interface implementeert, zo ja: Cast hem en je hebt een verwijziging naar het object via de interface.

[Verwijderd]

Dan cast ik het object naar een (bekende) Interface, maar helaas ken ik die Interface niet compile-time. En ik wil het eigenlijk niet casten naar een Interface, ik wil bijv. obj MyInterface laten implementen.

[misfire]

Het was zeker niet mijn bedoeling om minachtend te reageren. Ik probeerde alleen nadrukkelijk aan te geven dat wat je wilt wellicht nog te hoog gegrepen voor je is gegeven op welke manier je het uitdrukt en hoe je met termen omgaat. Dat bedoel ik heel positief. Het is nooit verkeerd om de randen van de techniek op te zoeken, daar leer je het meeste van.

Het is alleen niet zo slim om meteen in het diepe te springen, om vervolgens een leven lang een chloorsmaak in de mond te krijgen zodra je de term "Java" hoort... Als je eerst nog eens wat gaat spelen met Java en je nog wat meer verdiept in een aantal mechanismes, voordat je aan dit soort trucs gaat beginnen dan lukt het je vast, en dan beleef je er ook veel meer plezier aan! En als je dan toch nog een vraag hebt, dan snappen wij ook waar je het over hebt.

[voodooless]

Volgens mij ben jij een heel moeilijke oplossing aan het zoeken voor iets relatief simpels. Het is waarschijnlijk inmiddels wel duidelijk dat wat jij wil niet zomaal kan (zonder veel hacking e.d.)... (misshien heeft iemand anders nog een geniale ingeving...)

Kun je niet eerst gebruik maken van bekende interfaces, die je gewoon de naam van de onbekende interface terug geven... Als je eenmaal de naam hebt ben je al een stuk verder.

Maar wat wil je eigenlijk met die onbekende inerface? Als je eenmaal een instantie hebt (als dat dus lukt), lijkt het me dat het ook onbekend is welke methodes je wil aanroepen, laat staan de volgorde: met andere woorden. Je hebt staks een volledig onbekende classe, ik vraag wat je (de VM@runtime) er dan mee wil gaan doen als je (de VM@runtime) niet eens weet wat het doet

[vinnux]

Verwijderd schreef op 13 juni 2004 @ 22:20:Als je nog weet waarom Sun voor die beperking heeft gekozen hoor ik het natuurlijk graag, maar laten we nou niet gaan zitten discussieren want zo zal niemand meer hier vragen gaan stellen.
_{Is dat slecht?}

MMM ik heb hier een klasse. Ik ken hem niet.Hmm is kijken. Hé een functie he en nog één. Goh ja laat ik die maar voor de gein is aanroepen. He hij wist mijn harde schijf, en eehhhhhhh help hij killed me.
Is wel een hele makkelijke exploit he

En zeer af te raden werkwijze, vandaar dat het wel zo moeilijk zal zijn he
Je kunt natuurlijk altijd zelf herschijvende code maken die zich compileert en weer opstart. Maar dan wordt het nog 10000X ranziger.

Misschien dat een taal als C of C++ je hier beter bij kan helpen. Die zijn, om flames te voorkomen, krachtiger.

[ Voor 67% gewijzigd door vinnux op 15-06-2004 18:13 ]

[drm]

Even tussendoor: de topicstart en/of de manier van vragen is niet hetgeen dat hier ter discussie staat. Laten we het over Java (en/of C++ vgouw) blijven houden. Dank voor de medewerking

[ Voor 5% gewijzigd door drm op 15-06-2004 18:14 ]

[.oisyn]

misfire schreef op 13 juni 2004 @ 20:41:
Je beweert wel degelijk dat Java verkeerd met allerlei begrippen om zou gaan. Een interface is dus niet een abstract class. Het zijn echt aparte dingen. Doe eens een Java cursus of lees een goed boek zou ik zeggen.

Een interface is in feite wel degelijk precies hetzelfde als een abstracte klasse met alleen maar abstracte functies. Dat java daar toevallig 2 verschillende keywords voor heeft bedacht, namelijk classes en interfaces, heeft te maken met het feit dat Java geen volledige multiple inheritance implementeert. Maar verder zijn de twee niet verschillend.

C++ heeft daarentegen wel MI, en is er dus geen nut voor enig verschil tussen een class en een interface. Hoe definieer je dan een interface in C++? Door simpelweg een klasse te maken met alleen maar abstracte methoden.

[ Voor 4% gewijzigd door .oisyn op 16-06-2004 02:08 ]

[Bobco]

Ik heb het hele topic nog eens doorgelezen en mijn reactie was dezelfde als IceManX: wat wil je nu in godsnaam bereiken? Als ik het goed begrijp heb je een willekeurig object en daar wil je runtime dingen aan toevoegen door er voor te zorgen dat er een op te geven interface geimplementeerd wordt.

Naar mijn gevoel is dat niet mogelijk zonder byte-code manipulatie, iets dat naar mijn smaak alleen moet worden gedaan als het echt nodig is. Bovendien zul je ook nog ergens een implementatie van die interface tevoorschijn moeten toveren, anders heb je alsnog alleen maar een tag interface aan je object gehangen.

Het is mij na het lezen van het complete topic nog steeds niet duidelijk wat je nu precies wilt. Beschrijf het functionele probleem eens, dan wordt het misschien ook duidelijker voor ons wat je nu wilt.

[Verwijderd]

deepspace schreef op 14 juni 2004 @ 20:17:
Volgens mij ben jij een heel moeilijke oplossing aan het zoeken voor iets relatief simpels. Het is waarschijnlijk inmiddels wel duidelijk dat wat jij wil niet zomaal kan (zonder veel hacking e.d.)... (misshien heeft iemand anders nog een geniale ingeving...)

Kun je niet eerst gebruik maken van bekende interfaces, die je gewoon de naam van de onbekende interface terug geven... Als je eenmaal de naam hebt ben je al een stuk verder.

Maar wat wil je eigenlijk met die onbekende inerface? Als je eenmaal een instantie hebt (als dat dus lukt), lijkt het me dat het ook onbekend is welke methodes je wil aanroepen, laat staan de volgorde: met andere woorden. Je hebt staks een volledig onbekende classe, ik vraag wat je (de VM@runtime) er dan mee wil gaan doen als je (de VM@runtime) niet eens weet wat het doet

Ik wil iedereen aanraden om even goed te lezen wat ik allemaal zeg, want ik moet telkens in herhaling vallen (nofi).
Opgesomt:
- Ik 'ken' de Interface, dwz: haar classname en gewoon de volledige code (dus ook methods etc.)
- Echter, ik kan deze niet importen
- Ik weet dus heel goed welke methods ik dien te implementen, ik heb in feite een aparte klasse die volledig functioneel is op één ding na: het ontbreekt hem aan een "implements" keyword met daarachter de Interface-naam.
- Ik wil runtime aangeven dat die bewuste klasse die Interface moet implementen (ja, ik weet het, als je een method niet/onjuist implement is het "panic" in de VM aangezien je dit niet met de compiler kunt afvangen )
- Ik weet (natuurlijk, anders zou het wel onzinnig zijn) wel de naam van de Interface, en weet de .class file ook te vinden uiteraard.

Als ik die naam heb ben ik al een stuk verder ja... en dan?

[Verwijderd]

vgouw schreef op 15 juni 2004 @ 18:02:
[...]


MMM ik heb hier een klasse. Ik ken hem niet.Hmm is kijken. Hé een functie he en nog één. Goh ja laat ik die maar voor de gein is aanroepen. He hij wist mijn harde schijf, en eehhhhhhh help hij killed me.
Is wel een hele makkelijke exploit he

Dat is natuurlijk onzin, ik weet heel goed wat ik wil en doe, ik loop niet lukraak met onbekende Interfaces te klooien. Dit gevaar zou dan evenwel bestaan bij het instantiaten van een .class-file dmv bijv. Class.forName("oeh_ditIsGevaarlijk");.
En Java applicaties kunnen niet zomaar je schijf formatteren natuurlijk.

En zeer af te raden werkwijze, vandaar dat het wel zo moeilijk zal zijn he
Je kunt natuurlijk altijd zelf herschijvende code maken die zich compileert en weer opstart. Maar dan wordt het nog 10000X ranziger.

Helaas wel ja, maar dat zou dus helemaal niet nodig moeten zijn.

Misschien dat een taal als C of C++ je hier beter bij kan helpen. Die zijn, om flames te voorkomen, krachtiger.

Ik vind het ook onzin dat bijv. multiple inheritance niet in Java is opgenomen. De genoemde "schaduwzijden" zijn stuk voor stuk te voorkomen als de programmeur fatsoenlijk kijkt wat hij doet (bijv. geen meerdere klassen maken met dezelfde methods, en een andere class van al deze classes de methods laten inheriten ).

[ Voor 4% gewijzigd door Verwijderd op 16-06-2004 20:02 ]

[Alarmnummer]

Verwijderd schreef op 16 juni 2004 @ 20:00:
[...]

Dat is natuurlijk onzin, ik weet heel goed wat ik wil en doe, ik loop niet lukraak met onbekende Interfaces te klooien. Dit gevaar zou dan evenwel bestaan bij het instantiaten van een .class-file dmv bijv. Class.forName("oeh_ditIsGevaarlijk");.
En Java applicaties kunnen niet zomaar je schijf formatteren natuurlijk.

Als je een normale applicatie hebt is dat geen probleem hoor. Tenminste.. ik neem aan dat je onder windows werkt en dat je als admin bent ingelogt (zoals ik zelf ook)

Ik vind het ook onzin dat bijv. multiple inheritance niet in Java is opgenomen. De genoemde "schaduwzijden" zijn stuk voor stuk te voorkomen als de programmeur fatsoenlijk kijkt wat hij doet (bijv. geen meerdere klassen maken met dezelfde methods, en een andere class van al deze classes de methods laten inheriten ).

Daar kom je soms niet onder uit. En verder heb ik ook niet veel klasses die van meerdere classes/interfaces moeten extenden. Meestal los ik het op door een innerclass die interface te laten implementeren en die als delegate zijn werk te laten doen (ik geloof dat c++ geen innerclasses heeft). Ik zal verder maar geen discussie houden over wel of geen multiple inheritenance want daarover is hier al vaak discussie gevoerd.

[Verwijderd]

Bobco schreef op 16 juni 2004 @ 10:18:
Ik heb het hele topic nog eens doorgelezen en mijn reactie was dezelfde als IceManX: wat wil je nu in godsnaam bereiken? Als ik het goed begrijp heb je een willekeurig object en daar wil je runtime dingen aan toevoegen door er voor te zorgen dat er een op te geven interface geimplementeerd wordt.

Naar mijn gevoel is dat niet mogelijk zonder byte-code manipulatie, iets dat naar mijn smaak alleen moet worden gedaan als het echt nodig is.

Maar daar betrap ik je wel op een denkfout. Ik zeg niet dat ik byte-code wil (kunnen) manipuleren, ik zeg iets te willen waarvan jij zegt dat dat op dit moment alleen op deze wijze kan. Dat is natuurlijk iets heel anders, mij hoor je ook niet ontkennen dat je alleen in uiterste gevallen op dit soort methodieken moet terugvallen, zoals ik eerder ook al beaam.

Bovendien zul je ook nog ergens een implementatie van die interface tevoorschijn moeten toveren, anders heb je alsnog alleen maar een tag interface aan je object gehangen.

Hoe bedoel je?
Die class is volledig geprepareerd om in theorie deze Interface te kunnen implementen, dus het zou juist mogelijk moeten zijn om die implementatie toe te passen dmv enkel een tagje oid.

Het is mij na het lezen van het complete topic nog steeds niet duidelijk wat je nu precies wilt.

Toch wat beter lezen dan.

Beschrijf het functionele probleem eens, dan wordt het misschien ook duidelijker voor ons wat je nu wilt.

Maar daar heb ik al in een vroeg stadium van gezegd dat ik dat pad hier niet wil inslaan, want ik weet gewoon dat je dan weer discussies krijgt (ook jullie onderling) en dat is niet wat ik beoogde met dit topic.
Verder heb ik al gezegd dat ik dit praktische probleem reeds anders heb opgelost, maar dat betekent niet dat ik niet geinteresseerd ben naar de mogelijkheden van Java wat dit betreft.

[Verwijderd]

Alarmnummer schreef op 16 juni 2004 @ 20:08:
[...]

Als je een normale applicatie hebt is dat geen probleem hoor. Tenminste.. ik neem aan dat je onder windows werkt en dat je als admin bent ingelogt (zoals ik zelf ook)

Ik werk niet (altijd) onder Windows, maar ben dan wel als admin ingelogd ja.
Volgens mij moest je de SecurityManager aanroepen om dit soort privileges te verkrijgen...
Of is die in de laatste JVM al gekoppeld aan de ACL-functionaliteit van Windows?
edit:
Applets kunnen niet formatteren, zo was het.

[...]

Daar kom je soms niet onder uit. En verder heb ik ook niet veel klasses die van meerdere classes/interfaces moeten extenden. Meestal los ik het op door een innerclass die interface te laten implementeren en die als delegate zijn werk te laten doen (ik geloof dat c++ geen innerclasses heeft). Ik zal verder maar geen discussie houden over wel of geen multiple inheritenance want daarover is hier al vaak discussie gevoerd.

Waar kom je niet onder uit?
Inner classes zijn een logisch <-> semantisch gedrocht.

offtopic:
Worden meer mensen tureluurs van mijn avatar onder FireFoix 0.9 ?

[ Voor 9% gewijzigd door Verwijderd op 16-06-2004 20:20 ]

[Alarmnummer]

Verwijderd schreef op 16 juni 2004 @ 20:14:
[...]

Ik werk niet (altijd) onder Windows, maar ben dan wel als admin ingelogd ja.
Volgens mij moest je de SecurityManager aanroepen om dit soort privileges te verkrijgen...
Of is die in de laatste JVM al gekoppeld aan de ACL-functionaliteit van Windows?

Als jij een normale Java applicatie draait (bv een commandline tool) dan heeft ie dezelfde rechten zoals iedere andere applicatie.

Waar kom je niet onder uit?

Dat het in een interfaceloze taal sneller gebeurt dat je van meerdere clases moet extenden. Vooral omdat je ook nog een geen innerclasses hebt, dus ook niet op een andere (nette) manier bij de inhoud van een class kan komen.

Inner classes zijn een logisch <-> semantisch gedrocht.

Hoeveel ervaring heb jij eigelijk met programmeren/programmeren in Java? Delagates zijn een ware uitkomst doordat je op kleine subtaken kunt concentreren en een afgezand(delegate) de deur uit kunt doen om die taak af te handelen. Dus ipv dat een class alles zelf moet oplossen (waardoor hij meerdere clases moet extenden) kan hij dit overlaten aan zo`n delegate (die verder volledige toegang heeft binnen die class). Het geeft een heer licht, inzichtelijk ontwerp.

code:

class Persoon implements KoffieIsKlaarListener{

       void koffieIsKlaar(KoffieEvent e){
              ...
       }
}

class Persoon{

      private class KoffieIsKlaarListenerImpl implements KoffieIsKlaarListener{
            void koffieIsKlaar(KoffieEvent e){
                   ....
            }
      }
}

Ik vind het laatste voorbeeld toch echt een stuk fijner. Aub geen commentaar op het voorbeeld zelf

[ Voor 19% gewijzigd door Alarmnummer op 16-06-2004 20:25 ]

[voodooless]

Verwijderd schreef op 16 juni 2004 @ 19:54:
[...]

Ik wil iedereen aanraden om even goed te lezen wat ik allemaal zeg, want ik moet telkens in herhaling vallen (nofi).
Opgesomt:
- Ik 'ken' de Interface, dwz: haar classname en gewoon de volledige code (dus ook methods etc.)
- Echter, ik kan deze niet importen
- Ik weet dus heel goed welke methods ik dien te implementen, ik heb in feite een aparte klasse die volledig functioneel is op één ding na: het ontbreekt hem aan een "implements" keyword met daarachter de Interface-naam.
- Ik wil runtime aangeven dat die bewuste klasse die Interface moet implementen (ja, ik weet het, als je een method niet/onjuist implement is het "panic" in de VM aangezien je dit niet met de compiler kunt afvangen )
- Ik weet (natuurlijk, anders zou het wel onzinnig zijn) wel de naam van de Interface, en weet de .class file ook te vinden uiteraard.

Als ik die naam heb ben ik al een stuk verder ja... en dan?

Het is niet zozeer het goed lezen, maar meer het goed begrijpen wat je wil... Dat is nu al stukken duidelijker:)

Je hebt gewoon een klasse die een interface implementeerd, zonder dat er in de code een implements staat... toch?

Nu wil je run-time op de een of andere manier deze interface bij die classe frotten, zodat je deze via de interface kunt benaderen... ja?

Volgens mij kan dat idd bijna alleen alleen als je run-time bytecode gaat hacken. Andere truck: maak runtime een nieuw java bestand:

Java:

public class helpclasse extends jeClass implements jeInterface{
// verder leeg
}

Deze moet je dan runtime compileren en dan heb je een klasse die de interface implementeerd en de methodes heeft van de orginele klasse. Beetje een omweg, maar volgens mij moet dat kunnen.

Maar vaag: Wat is het probleem om bij de code van je classe erbij te zetten dat die die interface implemeteerd? Dan ben je toch gewoon van het gehele gezeur af!

offtopic:
Worden meer mensen tureluurs van mijn avatar onder FireFoix 0.9 ?

Yep

[ Voor 6% gewijzigd door voodooless op 16-06-2004 20:30 ]

[Verwijderd]

Alarmnummer schreef op 16 juni 2004 @ 20:19:
[...]

Als jij een normale Java applicatie draait (bv een commandline tool) dan heeft ie volledige rechten zoals iedere andere applicatie.

Zie laatste edit.

[...]

Dat het in een interfaceloze taal sneller gebeurt dat je van meerdere clases moet extenden. Vooral omdat je ook nog een geen innerclasses hebt, dus ook niet op een andere (nette) manier bij de inhoud van een class kan komen.

Maar het feit dat een taal geen inner classes heeft is natuurlijk geen logisch gevolg van het feit dat hij interfaceloos is.
Verder is dat extenden (van abstracte classes dan) de vervanger van Interfaces in Java dus het maakt weinig uit of je er wel of niet onderuit komt toch?

[...]

Hoeveel ervaring heb jij eigelijk met programmeren/programmeren in Java? Delagates zijn een ware uitkomst doordat je op kleine subtaken kunt concentreren en een afgezand(delegate) de deur uit kunt doen om die taak af te handelen. Dus ipv dat een class alles zelf moet oplossen (waardoor hij meerdere clases moet extenden) kan hij dit overlaten aan zo`n delegate. Het geeft een heel licht, inzichtelijk ontwerp.

Niet echt veel, ik doe uit mezelf ervaring op en leer zaken op het moment dat het mij uitkomt. Maar ik heb er wel aardig inzicht in hoor, om even onbescheiden te doen.
Erg lui etc., maar aan het voorkauwen van stof zoals ze op je studie doen heb je vrij weinig.

Dat kan ook met delegates in een aparte (en niet inner) class. Gewoon een Vector (of ArrayList, Hashmap, enz. ) vullen met deze delegates en die zaken waar toegang tot zou moeten zijn doorgeven via een soort van inter-class communication.
Ja ik weet het, dat is weer onnodig traag/complex/noem maar op, maar zo zou ik zoiets standaard aanpakken.

[Bobco]

Verwijderd schreef op 16 juni 2004 @ 20:08:
[...]

Maar daar betrap ik je wel op een denkfout. Ik zeg niet dat ik byte-code wil (kunnen) manipuleren, ik zeg iets te willen waarvan jij zegt dat dat op dit moment alleen op deze wijze kan. Dat is natuurlijk iets heel anders, mij hoor je ook niet ontkennen dat je alleen in uiterste gevallen op dit soort methodieken moet terugvallen, zoals ik eerder ook al beaam.

Ik blijf dit een nogal kunstmatig probleem vinden. Je wilt je applicatie laten werken met classes die je at compile time niet kent, maar waarvan je wel verwacht dat ze een bepaalde interface implementeren, alhoewel dat niet expliciet is aangegeven met een implements.

Het lijkt me dat er stapels applicaties zijn die op deze manier classes aanroepen en gebruiken, servlets zijn er een simpel voorbeeld van. Als je dynamisch wilt kunnen bepalen welke interface van toepassing is op een bepaalde class ontkom je niet aan reflection en/of byte-code manipulatie.

Maar ondanks dat jij hardnekkig blijft weigeren om te vertellen waar dit nu allemaal om begonnen is ben ik toch wel heel nieuwsgierig naar de toepassing die jij in gedachten hebt...

[Verwijderd]

deepspace schreef op 16 juni 2004 @ 20:28:
[...]


Het is niet zozeer het goed lezen, maar meer het goed begrijpen wat je wil... Dat is nu al stukken duidelijker:)

Dat begrip zou moeten volgen uit het zorgvuldig lezen van het topic.

Je hebt gewoon een klasse die een interface implementeerd, zonder dat er in de code een implements staat... toch?

Dat zou ik graag willen ja.

Nu wil je run-time op de een of andere manier deze interface bij die classe frotten, zodat je deze via de interface kunt benaderen... ja?

Ja. Maar ik wil niets via die Interface benaderen, die Interface genereert gewoon zelfstandig events (zal wel niet goed verwoord zijn ivm Listener/Adapters maar you get the point hoop ik )

Volgens mij kan dat idd bijna alleen alleen als je run-time bytecode gaat hacken. Andere truck: maak runtime een nieuw java bestand:

Java:

public class helpclasse extends jeClass implements jeInterface{
// verder leeg
}

Deze moet je dan runtime compileren en dan heb je een klasse die de interface implementeerd en de methodes heeft van de orginele klasse. Beetje een omweg, maar volgens mij moet dat kunnen.

(Hier spreekt de JVM):
<java: Welke Interface bedoelt u, meneer deepspace?>

Maar vaag: Wat is het probleem om bij de code van je classe erbij te zetten dat die die interface implemeteerd? Dan ben je toch gewoon van het gehele gezeur af!

OMG
Probleem is al opgelost!!
Nu kunnen we toch heerlijk verder discussieren over het hoe & waarom rond dit (theorethische) probleem?

[Alarmnummer]

Verwijderd schreef op 16 juni 2004 @ 20:30:
Maar het feit dat een taal geen inner classes heeft is natuurlijk geen logisch gevolg van het feit dat hij interfaceloos is.

Ja en?

Verder is dat extenden (van abstracte classes dan) de vervanger van Interfaces in Java

Bij een abstracte class kan je niet garanderen dat er geen implementaties/velden aanwezig zijn en bij een interface wel. Een interface is dus een sterke eis dan een abstracte class.

dus het maakt weinig uit of je er wel of niet onderuit komt toch?

Developen is niet een kwestie van ergens onder uit komen maar een goeie oplossing te bedenken voor een probleem. En de snelste oplossing is niet altijd de beste oplossing, omdat een groot deel van de tijd ook code onderhouden moet worden en niet van die schoolvoorbeeldjes zijn die je daarna weg kan flikkeren. Dus eisen als onderhoudbaarheid zijn gewoon een must voor software als het kans van slagen wil hebben. Zoek anders even naar: stove pipe systems.

Niet echt veel, ik doe uit mezelf ervaring op en leer zaken op het moment dat het mij uitkomt. Maar ik heb er wel aardig inzicht in hoor, om even onbescheiden te doen.

Zoals bobco al zei, je hebt een enorm kunstmatig probleem die eigelijk ook niet bijster interessant is om op te lossen.

Dat kan ook met delegates in een aparte (en niet inner) class. Gewoon een Vector (of ArrayList, Hashmap, enz. ) vullen met deze delegates en die zaken waar toegang tot zou moeten zijn doorgeven via een soort van inter-class communication.

Doe dan niet zo ingewikkeld en maak alle velden dan lekker public.

[ Voor 4% gewijzigd door Alarmnummer op 16-06-2004 20:40 ]

[Verwijderd]

Bobco schreef op 16 juni 2004 @ 20:32:
[...]
[...]
Daarom was het ook opgelost.

[]Je wilt je applicatie laten werken met classes die je at compile time niet kent, maar waarvan je wel verwacht dat ze een bepaalde interface implementeren, alhoewel dat niet expliciet is aangegeven met een implements.

Juist. Is zo gek toch niet, in theorie?

Het lijkt me dat er stapels applicaties zijn die op deze manier classes aanroepen en gebruiken, servlets zijn er een simpel voorbeeld van. Als je dynamisch wilt kunnen bepalen welke interface van toepassing is op een bepaalde class ontkom je niet aan reflection en/of byte-code manipulatie.

Reflection lijkt me ook ja, maar byte-code manipulatie vind ik een te zwaar (en lelijk) middel. Via byte-code manipulatie kan je wel meer... maar of dat zo wenselijk is?

Maar ondanks dat jij hardnekkig blijft weigeren om te vertellen waar dit nu allemaal om begonnen is ben ik toch wel heel nieuwsgierig naar de toepassing die jij in gedachten hebt...

Als ik dit al zou willen zouden mijn projectleden dit niet echt op prijs stellen.
Maar een simpel voorbeeld is wat ik al zei in het begin, als je libraries niet import maar dynamisch load, en je gebruikt ergens een nogal netelige Interface-constructie zal je dit weldra tegenkomen denk ik...

[Alarmnummer]

Verwijderd schreef op 16 juni 2004 @ 20:43:
[...]
Als ik dit al zou willen zouden mijn projectleden dit niet echt op prijs stellen.
Maar een simpel voorbeeld is wat ik al zei in het begin, als je libraries niet import maar dynamisch load, en je gebruikt ergens een nogal netelige Interface-constructie zal je dit weldra tegenkomen denk ik...

Ok tip: als je met crap constructies bezig moet... dan is de kans redelijk groot dat je ontwerp dus gewoon zuigt.

[voodooless]

Verwijderd schreef op 16 juni 2004 @ 20:38:
Dat begrip zou moeten volgen uit het zorgvuldig lezen van het topic.

Dat zie ik dus absoluut niet zo. Ik ben immers niet de enigste die het niet duidelijk vond. Met iedere letter drie keer uitpluizen wordt het er echt niet beter op.

Ja. Maar ik wil niets via die Interface benaderen, die Interface genereert gewoon zelfstandig events (zal wel niet goed verwoord zijn ivm Listener/Adapters maar you get the point hoop ik )

Dat maakt toch niet uit. Je zult die die interface (implementatie) instantie (zo zal ik het maar ff noemen), toch wel moeten zeggen waar hij z'n ei kwijt kan. Die events moeten immers ergens heen gaan.

(Hier spreekt de JVM):
<java: Welke Interface bedoelt u, meneer deepspace?>

Hoezo welke interface... Je zegt net zelf:

- Ik 'ken' de Interface, dwz: haar classname en gewoon de volledige code (dus ook methods etc.)

Je kent de classname en code, dus kun je die ook in een run-time gegenereede java file dumpen...

OMG
Probleem is al opgelost!!
Nu kunnen we toch heerlijk verder discussieren over het hoe & waarom rond dit (theorethische) probleem?

Bij deze dan...

[Verwijderd]

Alarmnummer schreef op 16 juni 2004 @ 20:38:
[...]

Ja en?

Nou dat!
Je impliceerde het tegendeel.

[...]

Bij een abstracte class kan je niet garanderen dat er geen implementaties/velden aanwezig zijn en bij een interface wel. Een interface is dus een sterke eis dan een abstracte class.

Bedoel je geen velden anders dan die in de Interface zelf gedefineerd worden?
Ja, dat is waar. Hebben ze daar bij C++ dan niks op gevonden?

[...]

Developen is niet een kwestie van ergens onder uit komen maar een goeie oplossing te bedenken voor een probleem. En de snelste oplossing is niet altijd de beste oplossing, omdat een groot deel van de tijd ook code onderhouden moet worden en niet van die schoolvoorbeeldjes zijn die je daarna weg kan flikkeren. Dus eisen als onderhoudbaarheid zijn gewoon een must voor software als het kans van slagen wil hebben. Zoek anders even naar: stove pipe systems.

Heb je volledig gelijk in, is ook niet in tegenspraak met wat ik zeg. Maar we gaan wel weer offtopic.

[...]

Zoals bobco al zei, je hebt een enorm kunstmatig probleem die eigelijk ook niet bijster interessant is om op te lossen.

Voor mij is het interessant genoeg. Ik wil gewoon weten of het kan ja/nee. Zo nee, dan weet ik dat en daar denk ik dan het mijne van.

[...]

Doe dan niet zo ingewikkeld en maak alle velden dan lekker public.

Ik zei zelf idd al dat het ingewikkeld is.
Maar public is wél veel krakkemikkiger/lelijker...

[Alarmnummer]

Verwijderd schreef op 16 juni 2004 @ 20:51:
[...]
Bedoel je geen velden anders dan die in de Interface zelf gedefineerd worden?
Ja, dat is waar. Hebben ze daar bij C++ dan niks op gevonden?

Puur virtuele classes (dus interfaces) bestaan niet bij c++. Je kan het tenminste niet compiletechnisch afdwingen.

Maar public is wél veel krakkemikkiger/lelijker...

Lood om oud ijzer. Het zijn gewoon kutoplossingen.

[Verwijderd]

Alarmnummer schreef op 16 juni 2004 @ 20:46:
[...]

Ok tip: als je met crap constructies bezig moet... dan is de kans redelijk groot dat je ontwerp dus gewoon zuigt.

Hehe...
Wat was ook al weer de status van dit probleem.... ?


Design gewijzigd, opgelost!

Maar als dit zonder poespas zou kunnen (bijv. dmv van de reflection API) is het geen crap-constructie natuurlijk.

[Verwijderd]

deepspace schreef op 16 juni 2004 @ 20:48:
[...]


Dat zie ik dus absoluut niet zo. Ik ben immers niet de enigste die het niet duidelijk vond. Met iedere letter drie keer uitpluizen wordt het er echt niet beter op.

Nou ik heb het duidelijk gezegd in de start post en een eindje verder, toen bij een ander ook het kwartje viel, heb ik het nog eens herhaald...

[...]


Dat maakt toch niet uit. Je zult die die interface (implementatie) instantie (zo zal ik het maar ff noemen), toch wel moeten zeggen waar hij z'n ei kwijt kan. Die events moeten immers ergens heen gaan.

Precies, en hoe doe ik dat run-time?

[...]


Hoezo welke interface... Je zegt net zelf:

[...]

Je kent de classname en code, dus kun je die ook in een run-time gegenereede java file dumpen...

Dat is een vergelijkbare oplossing als byte-code manipulatie...
Maar is op zich wel een idee, want dmv de reflection API kun je wel dynamisch een Class-object opbouwen, zou er ook een voorziening zijn voor het implements-keyword?

[Alarmnummer]

Verwijderd schreef op 16 juni 2004 @ 20:54:
Maar als dit zonder poespas zou kunnen (bijv. dmv van de reflection API) is het geen crap-constructie natuurlijk.

Reflection is in 99% van de gevallen ook een crap oplossing. Je kan compiletime geen garanties geven (pas runtime). En we zijn in de it altijd zo blij als de compiler ons al zoveel mogelijk kan wijzen op fouten ipv dat je het runtime tegenkomt (misschien.. misschien niet.. misschien wel dat na 10 week de buggy code geexecute wordt).

Advies: leer ontwerpen, leer patterns.

[ Voor 5% gewijzigd door Alarmnummer op 16-06-2004 20:59 ]

[Verwijderd]

Alarmnummer schreef op 16 juni 2004 @ 20:54:
[...]

Puur virtuele classes (dus interfaces) bestaan niet bij c++. Je kan het tenminste niet compiletechnisch afdwingen.

C++'s bad.

[...]

Lood om oud ijzer. Het zijn gewoon kutoplossingen.

Precies, is de goede wel mogelijk?

[ Voor 3% gewijzigd door Verwijderd op 16-06-2004 20:59 ]

[Alarmnummer]

Verwijderd schreef op 16 juni 2004 @ 20:59:
Precies, is de goede wel mogelijk?

Een delegate is een goeie oplossing.

[Verwijderd]

Alarmnummer schreef op 16 juni 2004 @ 20:58:
[...]

Reflection is in 99% van de gevallen ook een crap oplossing. Je kan compiletime geen garanties geven (pas runtime). En we zijn in de it altijd zo blij als de compiler ons al zoveel mogelijk kan wijzen op fouten ipv dat je het runtime tegenkomt (misschien.. misschien niet.. misschien wel dat na 10 week de buggy code geexecute wordt).

Advies: leer ontwerpen, leer patterns.

Dat maakt het nog geen crap-oplossing...
Als je goed test is het theoretisch gezien net zo solide code...
Maar idd, het is wel een praktische keerzijde.

Ontwerpen en patterns doe/ken ik al waar nodig, verder is het geen professionele toepassing dus ik pak het ook niet zo aan, het is alleen maar om wat te leren. Als je alles meteen goed doet kom je in moeilijke gevallen later in de problemen.

[Verwijderd]

Alarmnummer schreef op 16 juni 2004 @ 21:01:
[...]

Een delegate is een goeie oplossing.

Oplossing wel, maar het blijft een logisch <-> semantisch gedrocht.
Maar ja, dat is wellicht inherent aan Java.

[curry684]

even nogmaals een vriendelijk verzoek om een en ander helder, ontopic en vriendelijk te houden dank u

Cybarite: ben je niet toevallig op zoek naar een Java-variant van de (D)COM-interface IDispatch? Zo nee sluit ik me aan bij de rest van de profs hier die geen bal van je probleem snapt

[Verwijderd]

Volgens mij is alles aardig vriendelijk, meer zelfs dan je zou verwachten op GoT in dit soort topics...

Ik kan niet zeggen of ik op zoek ben naar IDispatch, aangezien ik dat niet ken (zal wel C++ zijn oid).

Verder heb ik nu al een paar keer gezegd dat het 'probleem' is opgelost. Dat wil zeggen er valt niets aan te begrijpen. Dan kunnen we nu (ontopic ) verder gaan met de discussie achter het hoe en waarom, als dit tenminste echt niet zou kunnen (die laatste suggestie van deepspace lijkt me nog het beste).

[voodooless]

Ik vind het eigenlijk ook wel redelijk vriendelijk..

Om maar ff in te haken op mijn oplossing:

Wat je dus eigenlijk moet doen is zelf een classe maken en de java compiler aanroepen. Ik heb hier een stukje gevonden over hoe dat zou kunnen:

http://www.javaworld.com/javatips/jw-javatip131.html

[Verwijderd]

Dat is idd hoe je het kunt doen. Echter wel tamelijk 'dirty'...

Maar goed, ik heb gezien dat je al dynamisch een class kunt opbouwen met de reflection API dus ik zal dat als ik tijd heb (= iig ná dit weekend ) eens uitzoeken. Code zal ik posten natuurlijk. Is weldegelijk interessant hoor.

[ Voor 3% gewijzigd door Verwijderd op 16-06-2004 22:36 ]

[curry684]

Verwijderd schreef op 16 juni 2004 @ 22:22:
Volgens mij is alles aardig vriendelijk, meer zelfs dan je zou verwachten op GoT in dit soort topics...

Ik kan niet zeggen of ik op zoek ben naar IDispatch, aangezien ik dat niet ken (zal wel C++ zijn oid).

Uhhhh, [google=IDispatch] en de eerste link klikken is toch niet zoveel moeite?

[Verwijderd]

curry684 schreef op 16 juni 2004 @ 23:22:
[...]

Uhhhh, [google=IDispatch] en de eerste link klikken is toch niet zoveel moeite?

Nee, maar wel offtopic.

Wat ik daar zie is een equivalent van de Java reflection API, en ik zie daardoor niks over interfaces of virtual classes die je dynamisch kan laten implementen....

Het kan zijn dat ik wat over het hoofd zie, maar ik heb dus geen zin afgerekend te worden op mijn uitspraken over MFC (), dus daarom liet ik me er niet over uit.

[ Voor 5% gewijzigd door Verwijderd op 16-06-2004 23:58 ]

[Verwijderd]

Alarmnummer schreef op 16 juni 2004 @ 20:08:

(ik geloof dat c++ geen innerclasses heeft).

Dat heeft ie wel zeker, zelfs C had dat al. Het heet overigens wel anders: Nested ipv Inner. Je gebruikt het bv ook wel met enums, of unions.

Wel werkt het iets anders. Er wordt bij C++ niet impliciet de this pointer van de outer class meegegeven. Je kunt alleen statics van de outer class benaderen. In principe is Java op dit punt dus wat 'sterker'.

Ter leering ende vermaeck, rechtstreeks uit de MSDN documentatie:

C++:

int x;
class enclose {
public:
   int x;
   static int s;
   class inner {
      void f() {
         x = 1;      // C2327; enclose::x is not static
         s = 1;      // ok; enclose::s is static
         ::x = 1;    // ok; ::x refers to global
      }
   };
};

[Verwijderd]

Het heet overigens wel anders: Nested ipv Inner.

What's in a name...

Java kan ook alleen de statics (?en/of finals?) benaderen van de outer class, als het in een this-context gebeurt.

Maar nu ontopic mensen.

[curry684]

Verwijderd schreef op 16 juni 2004 @ 23:56:
[...]

Nee, maar wel offtopic.

Wat ik daar zie is een equivalent van de Java reflection API, en ik zie daardoor niks over interfaces of virtual classes die je dynamisch kan laten implementen....

Het kan zijn dat ik wat over het hoofd zie, maar ik heb dus geen zin afgerekend te worden op mijn uitspraken over MFC (), dus daarom liet ik me er niet over uit.

Tis (D)COM, en IDispatch is de geeigende manier om aan een implementer die de feitelijke interface niet kent (die hoeft dus op compiletime nog niet te bestaan!!!) duidelijk te maken welke methods er zijn en welke parameters die nodig hebben. Deze methods kun je vervolgens via IDispatch::Invoke aanroepen zonder ooit een interface te hebben gezien.

Kan aan mij liggen, maar da's exact wat je wil zonder extreem ranzige bytecode trucs.

[Verwijderd]

Verwijderd schreef op 16 juni 2004 @ 23:56:
[...]

Wat ik daar zie is een equivalent van de Java reflection API, en ik zie daardoor niks over interfaces of virtual classes die je dynamisch kan laten implementen....

Als ik deze thread zo lees, dan begrijp ik het volgende:

(theoretisch) heb je:

A) Een classe X die je dynamisch laadt
Een interface Y waarvan je -weet- dat die volledig geimplementeerd wordt door de classe X
C) De compiler weet niet dat X eigenlijk ook een Y kan zijn, omdat je dit niet aangaf in de classe definitie.

Wat jij dus volgens mij zoekt is conceptueel simpel en lijkt enigsinds op de reinterpret_cast van C++. Hiermee zeg je tegen de compiler: Beschouw dit object voortaan als een [willekeurig class type].

In dit geval ligt de gehele verandwoordelijkheid dat de memory layout van het object klopt in jouw handen. 99% van de gevallen is reinterpret_cast een design fout, maar voor die 1% van de gevallen dat je uitgekiende low-level code schrijft kun je het gebruiken.

Wat C++ dan weer niet support is een dynamische naam van je target type. Echter, na dat je gecast hebt zul je toch iets willen doen met je object, bv aan een andere functie geven die een object van een bepaald type verwacht. In de praktijk zul je dus of de naam van je target type at compile weten in de code die de dynamisch geladen class gebruikt of je wilt wat anders doen met je object, maar dan heb je die reinterpret_cast niet nodig.

Bv, het volgende stukje laat zien dat je wel 2 compleet ongerelateerde classes naar elkaar kunt casten (hoewel dit echt slecht is in de praktijk), maardat je niet naar een type kunt casten waarbij het target type onbekend is:

C++:

template <typename T, typename S>
T dynamic_reinterpret_cast(S sourceType, T targetType) {
    return reinterpret_cast<T>(sourceType);
}

class Foo {
    public: void test() {
        std::cout << "In Foo" << std::endl;
    }
};

class BarBase {

    public: void test() {
        std::cout << "In Barbase" << std::endl;
    }

};

class Bar : public BarBase {
    public: void test() {
        std::cout << "In Bar" << std::endl;
    }
};

int main () { 

    BarBase* bar = new Bar; // dynamically obtained from 'somewhere'    

    Foo* foo = new Foo;

    // object treated as BarBase*, and (logically) not as a Bar*
    dynamic_reinterpret_cast(foo,bar)->test();

    return 0;
}

De 'domme' template die je in bovenstaande code ziet is dus overbodig en je kunt in dit geval de normale reinterpret_cast gebruiken.

edit: het bovenstaande voorbeeld werkt overigens ook als alle classes bv een member variable int a; hadden, je een waarde geeft aan a terwijl het object een Foo is, en dan vervolgens gebruikt als aan Bar:

C++:

class Foo {
    public: int a;
    public: void test() {
        std::cout << "In Foo a=" << a << std::endl;
    }
};

class Bar {
    public: int a;
    public: void test() {
        std::cout << "In Bar a=" << a << std::endl;
    }
};

int main () { 

    
    Foo* foo = new Foo;
    foo->a = 4;

    Bar* bar = reinterpret_cast<Bar*>(foo);
    
    bar->test(); // prints: In Bar a=4

    return 0;
}

Wat ik overigens nog niet heb gelezen (of mischien las ik overheen), wat gebeurt er precies met het dynamisch geladen object nadat ie 'de interface heeft gekregen'?

Is het de bedoeling dat het object aan een functie wordt doorgegeven die een object van het type van de interface verwacht of iets anders? In het geval van het eerste, is het type van de argumenten van deze functie bekend op de plek waar je de code gebruikt?

Dus bv:

code:

Object X = dynamisch geladen object;

Object Y = dynamisch geladen object;

Type T = Type van eerste argument van functie set() van X

Execute functie set( reinterpret_cast<T> (Y) ) van X;

Zoiets?

[ Voor 28% gewijzigd door Verwijderd op 17-06-2004 01:53 ]

[Verwijderd]

curry684 schreef op 17 juni 2004 @ 01:25:
[...]

Tis (D)COM, en IDispatch is de geeigende manier om aan een implementer die de feitelijke interface niet kent (die hoeft dus op compiletime nog niet te bestaan!!!) duidelijk te maken welke methods er zijn en welke parameters die nodig hebben. Deze methods kun je vervolgens via IDispatch::Invoke aanroepen zonder ooit een interface te hebben gezien.

Kan aan mij liggen, maar da's exact wat je wil zonder extreem ranzige bytecode trucs.

Dat is heel mooi, en daar blijkt dan pijnlijk uit:
dit is een gebrek in Java t.o.v. alternatieven (was het nou MFC? C#?).

Zo gek is mijn suggestie dus niet eens, zelfs MS heeft de moeite gedaan om dit mogelijk te maken.

[curry684]

Verwijderd schreef op 17 juni 2004 @ 01:35:
[...]

Dat is heel mooi, en daar blijkt dan pijnlijk uit:
dit is een gebrek in Java t.o.v. alternatieven (was het nou MFC? C#?).\

Ik zei al dat het (D)COM was, wat door VB, Java (!), C++, .NET en weet ik het wat gebruikt kan worden. Het ging me echter enkel om het principe, dit kun je in Java namelijk ook implementeren.

Echter, het is namelijk wederom een ranzige workaround om iets dat je in OOP gewoon niet moet willen: service without contract. Maar minder ranzig dan bytecode alteration.

In .NET is dit gelukkig stukken netter opgelost, daar wordt alles via SOAP gedaan, waardoor je alsnog een contract hebt met native interfacing.

Zo gek is mijn suggestie dus niet eens, zelfs MS heeft de moeite gedaan om dit mogelijk te maken.

COM in het algemeen wordt dan ook door de hele wereld (incluis Microsoft) gezien als Microsoft's stomste fout ooit.

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 19:27 ]

[whoami]

Eelis schreef op 17 juni 2004 @ 04:05:
[...]


[...]

Waarom zou je dat willen afdwingen?

Om een contract te definieren waar een class moet aan voldoen, zonder dat daar implementatie aan tepas komt.
Zie ook dit topic:
[rml][ java] klasse interface[/rml]

[ Voor 10% gewijzigd door whoami op 17-06-2004 08:38 ]

[.oisyn]

Dat legt niets uit, dat veranderd de vraag alleen maar

whoami schreef op 17 juni 2004 @ 08:37:
zonder dat daar implementatie aan tepas komt.

Waarom zou je dat willen afdwingen?

[vinnux]

Verwijderd schreef op 16 juni 2004 @ 20:00:
Ik vind het ook onzin dat bijv. multiple inheritance niet in Java is opgenomen. De genoemde "schaduwzijden" zijn stuk voor stuk te voorkomen als de programmeur fatsoenlijk kijkt wat hij doet (bijv. geen meerdere klassen maken met dezelfde methods, en een andere class van al deze classes de methods laten inheriten ).

Als de programmeur "goed" zou programeren was er helemaal geen behoeft aan 3de generatie talen etc. Maar er is gebleken dat een 2de generatie programma niet te beheren is boven een bepaald aantal regels. Door telkens de touwtjes van een nieuwe generatie taal aan te trekken en de programmeur te dwingen om bepaalde dingen op één manier op te lossen wordt je code onderhoudbaarder.

Programeurs maken nu eenmaal fouten en op deze manier voorkom je dat op een lager niveau.

[whoami]

Met een abstracte class ben je nooit zeker dat er geen implementatie bij komt kijken.

Als je verschillende objecten hebt, waarvoor je een bepaald 'contract' wilt specifiëren, kan het handig zijn dat je zeker weet dat er geen andere logica komt bij kijken.

[.oisyn]

whoami schreef op 17 juni 2004 @ 13:36:
Met een abstracte class ben je nooit zeker dat er geen implementatie bij komt kijken.

Dat weet je wel zeker, want je bent zelf de ontwerper van de interface. Het is niet zo dat de gebruiker van een interface ineens members en implementaties kan gaan toevoegen ofzo. Degene die een "interface" ontwerpt heeft zelf de keuze hoe hij die klasse in elkaar zet. In C++ is dat dus een klasse met alleen maar pure virtual methods. Daar zit geen implementatie in, en dat weet je ook zeker omdat je zelf de ontwerper bent van die interface. Ik vind het dus een non-argument .

Je zegt dus eigenlijk dat je wilt dat er wat syntactische suiker toe wordt gevoegd: introduceer een interface keyword, die ervoor zorgt dat alle members pure virtual zijn. Verder compilet het gewoon als iedere andere class. Dat vind ik eerlijk gezegd een beetje onzin eigenlijk

[ Voor 18% gewijzigd door .oisyn op 17-06-2004 13:44 ]

[whoami]

.oisyn schreef op 17 juni 2004 @ 13:39:
[...]


Dat weet je wel zeker, want je bent zelf de ontwerper van de interface.

Niet als ik een framework heb geschreven, en jij dat framework gebruikt.

[.oisyn]

Als jij een framework hebt geschreven, dan heb jij toch ook de interfaces ontworpen? Dan weet je toch zeker dat in de interface zelf geen implementatie zit?

[whoami]

Ja, maar als jij dat framework gebruikt, dan weet jij niet zeker of ik in de abstracte classes die ik in dat framework gestoken heb er geen implementatie in zit.

_{ik .... jij ... staat er in m'n vorige post}

[.oisyn]

Ik snapte wel wat je bedoelde, maar mijn punt is dat jij dan een fout ontwerp gemaakt hebt. Dat kan met Java en .Net net zo goed, door abstracte classes te gebruiken ipv interfaces, dan zit je met hetzelfde probleem. Door het gemis van MI is die fout in Java en .Net natuurlijk wel veel problematischer dan in C++, maar de fout is in essentie hetzelfde. Je kunt een compiler wel af laten dwingen dat een interface geen implementatie mag hebben, maar wat weerhoud jou ervan om een class te gebruiken ipv een interface? Analoog daaraan: wat weerhoud jou ervan om een implementatie toe te voegen aan een interface in C++? In beide gevallen heb je het gewoon niet begrepen en heb je een fout ontwerp geproduceerd.

Trouwens

dan weet jij niet zeker of ik in de abstracte classes die ik in dat framework gestoken heb er geen implementatie in zit

Dat weet ik wel zeker, dat kan ik namelijk in de header zien. Als alle members pure virtual zijn dan kan ik aannemen dat er geen implementatie is. (In werkelijkheid kan die implementatie er overigens wel zijn, maar dan moet ik die expliciet aan gaan roepen, en aangezien ik al aangenomen had dat die er niet was omdat alles pure virtual was, ga ik die dus ook niet aanroepen. De implementatie heeft dan dus ook niet echt veel nut)

[ Voor 34% gewijzigd door .oisyn op 17-06-2004 14:29 ]

[Verwijderd]

.oisyn schreef op 17 juni 2004 @ 13:45:

Als jij een framework hebt geschreven, dan heb jij toch ook de interfaces ontworpen? Dan weet je toch zeker dat in de interface zelf geen implementatie zit?

Volgens mij zitten Alarmnummer en whoami er toch wel een 'beetje' naast. Ik ben het dan ook meer met .oisyn eens in deze kwestie, alhoewel voor allebij de standpunten wel iets valt te zeggen.

Aan de ene kant klinken Alarmnummer en whoami overtuigend: Je kunt bij het aangeven dat een class een interface implementeerd in C++ niet aangeven dat het perse een interface moet zijn. Iemand kan dus 'stiekum' ipv de puur abstracte base class jouw class van een base laten inheritten die wel implementatie heeft.

Maar...

Als jij de ontwerper bent dan bepaal jij of dat gebeurt. Met de interfaces in Java heb je een zelfde soort probleem: iemand kan net zo goed 'stiekum' een methode weghalen in de definitie van de interface die jij implementeerd. Waarom is dit zoveel verschillend dan wanneer iemand in C++ 'stiekum' een implementatie toevoegt aan wat eerst een pure abstracte base was?

De bottomline is: Jij ontwikkeld de class, en daarbij ga je uit van bepaalde eigenschappen van de base. Als iemand jou class met een andere base gaat linken dan die jij bedoelde dan is er geen garantie dat alles nog goed gaat.

Java is dan mischien wel iets veiliger dan C++. Als de interface niet meer klopt compiled de code niet. In C++ zou een onbedoelde 'interface' verandering onopgemerkt kunnen gaan (omdat nu logica van de 'interface' kan worden uitgevoerd ipv de logica in de sub class). Echter, bij de gewone inheritance in Java zit je met precies hetzelfde probleem.

[whoami]

Met die abstracte class ben je nooit zeker dat er geen implementatie in de abstracte class zit. In sommige gevallen wil je dat nl. niet.

Een interface maak je, als je aan vele verschillende classes een bepaald 'contract' wilt toekennen.
Neem bv. de IList interface in .NET. Met die interface leg je een contract vast waar collection-classes moeten aan voldoen. Er zijn verschillende classes die die interface implementeren (ArrayList, DataView, ListItemCollection, .... ). Die classes hebben allemaal een andere implementatie, maar het zijn wel allemaal collecties.


Daarbij komt dan, dat bepaalde controls in .NET een property DataSource hebben, en die DataSource verwacht een object dat de IList implementeert. Hoe die methods precies geimplementeerd zijn, zal die control een worst wezen.

Wat zou het nut geweest zijn om daar een abstracte class te gebruiken ipv een interface ? Mocht daar een abstract class gebruikt zijn, dan zou dat ontwerp imo verkeerd geweest zijn.

Jij laat nu uitschijnen dat interfaces eigenlijk onnodig zijn.

[Alarmnummer]

Verwijderd schreef op 17 juni 2004 @ 14:28:
[...]
....

Een interface maakt het onmogelijk dat er velden/methodeimplementaties worden toegevoegd en dat is dus een groot verschil met een class. Dus puur door het feit dat je werkt met een interface als basis kan je dus onmogelijk implementaties/velden toe gaan voegen en kan je je ook niet zo snel laten verleiden om snel ff een veldje toe te voegen.

Een interface is dus een hulpmiddel voor een programmeur om een beter ontwerp te krijgen. In principe als een c++ programmeur zich echt heel strak houd aan een puur virtuele class en zich nooit laat verleiden om even een veld/implementatie toe te voegen, dan is er idd geen verschil tussen een interface en zo`n virtuele class. Het probleem is dat dit vaak wel gebeurt (in ieder geval wel met java en abstracte classes). Hierdoor zijn ineens een hele lading patterns niet meer van toepassing.

Maar het wil niet zeggen dat je dan overal maar interfaces voor moet gaan ontwerpen omdat je dan een log gebeuren krijgt. Ik maak interfaces voor lastige classes zodat ik een beetje het overzicht hou en ik maak interfaces voor classes waarvan ik zeker weet dat er subclasses gaan komen + een eventuele behoefte aan proxies,decoraties etc zou kunnen zijn. Anders zet ik mijn class gewoon op mbv een abstract class en ga niet onnodig interfaces lopen introduceren die totaal niet interessant zijn.

[ Voor 36% gewijzigd door Alarmnummer op 17-06-2004 14:40 ]

[whoami]

Verwijderd schreef op 17 juni 2004 @ 14:28:
[...]


Als jij de ontwerper bent dan bepaal jij of dat gebeurt. Met de interfaces in Java heb je een zelfde soort probleem: iemand kan net zo goed 'stiekum' een methode weghalen in de definitie van de interface die jij implementeerd. Waarom is dit zoveel verschillend dan wanneer iemand in C++ 'stiekum' een implementatie toevoegt aan wat eerst een pure abstracte base was?

Idd, iemand kan aan die interface definitie foefelen, maar, als je een goeie programmeur bent, dan roep je je member methods aan via een interface-instantie.
Als je dan die method aanroept, dan zal de compiler gaan klagen:

code:

void DoSomething( IMyInterface miep )
{
     miep.Process ();   // stel dat jij process uit de IMyInterface hebt gehaald, 
                         // dan compiled dit niet.
}

In C++ zou een onbedoelde 'interface' verandering onopgemerkt kunnen gaan (omdat nu logica van de 'interface' kan worden uitgevoerd ipv de logica in de sub class).

Niet als die class in C++ die je interface moet voorstellen alle methods als abstract heeft gedefinieerd.

[ Voor 3% gewijzigd door whoami op 17-06-2004 14:41 ]

[whoami]

Alarmnummer schreef op 17 juni 2004 @ 14:39:
[...]

Maar het wil niet zeggen dat je dan overal maar interfaces voor moet gaan ontwerpen omdat je dan een log gebeuren krijgt. Ik maak interfaces voor lastige classes zodat ik een beetje het overzicht hou en ik maak interfaces voor classes waarvan ik zeker weet dat er subclasses gaan komen + een eventuele behoefte aan proxies,decoraties etc zou kunnen zijn. Anders zet ik mijn class gewoon op mbv een abstract class en ga niet onnodig interfaces lopen introduceren die totaal niet interessant zijn.

Daarmee ben ik het eens.

[whoami]

Dit vond ik net:

Recommendations on using Abstract Classes and Interfaces
1. If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface.
2. If the functionality you are creating will be useful across a wide range of disparate objects, use an interface. Abstract classes should be used primarily for objects that are closely related, whereas interfaces are best suited for providing common functionality to unrelated classes.
3. If you are designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.
4. If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members.

[Verwijderd]

whoami schreef op 17 juni 2004 @ 14:35:
Jij laat nu uitschijnen dat interfaces eigenlijk onnodig zijn.

Nee joh! In het geval dat jouw class in java geen base heeft, maar alleen 1 enkele interface implementeerd is een abstracte class wel hetzelfde als een interface.

Aangezien C++ MI heeft, maakt het dus niet uit of je nu voor de abstracte class een apart interface keyword hebt. De C++ is krachtiger; je kunt met hetzelfde mechanisme zowel conceptuele interfaces realiseren, een 'gewone' base classe, alswel meerdere base classes.

(Aan MI zitten natuurlijk wel haken en ogen. Een vreemde cotcha is bv dat de volgorde van de base classes uitmaakt in je classe definitie: Je kunt van een object die MI gebruikt alleen van de eerste base class een pointer to member function nemen.)

Net zoals jij je verplicht om een contract na te komen, moet de opsteller van een contract zich verplichten om het contract een contract te laten zijn, en niet opeens wat anders er van maken. Dat is een grotere verandwoordelijkheid ja. C++ programmeurs nemen die.

[Alarmnummer]

Maar hoe vaak gebruik jij multiple inheritance terwijl je beter een delegate (inner class die die interface/abstract class implementeerd/extend)? Het gebeurt me al niet eens vaak meer dat een class meerdere interfaces implementeerd

[ Voor 24% gewijzigd door Alarmnummer op 17-06-2004 15:02 ]

[.oisyn]

whoami schreef op 17 juni 2004 @ 14:35:

Was dit trouwens een reactie op mij of op Henk? Indien dat laatste kun je deze post negeren

Met die abstracte class ben je nooit zeker dat er geen implementatie in de abstracte class zit. In sommige gevallen wil je dat nl. niet.

Je gaat een beetje aan het punt voorbij waar we het aanvankelijk over hadden. Namelijk interfaces van Java vs. de lack thereof in C++.

Een interface maak je, als je aan vele verschillende classes een bepaald 'contract' wilt toekennen.

Precies, hetzelfde geldt voor een pure abstracte class in C++

Daarbij komt dan, dat bepaalde controls in .NET een property DataSource hebben, en die DataSource verwacht een object dat de IList implementeert. Hoe die methods precies geimplementeerd zijn, zal die control een worst wezen.

Idd, dus geen implementatie, dan is je ontwerp goed

Wat zou het nut geweest zijn om daar een abstracte class te gebruiken ipv een interface ? Mocht daar een abstract class gebruikt zijn, dan zou dat ontwerp imo verkeerd geweest zijn.

Alleen verkeerd als die abstracte class een implementatie biedt voor een of meerdere methoden, en al helemaal als de taal waarin je werkt geen MI ondersteunt.

Jij laat nu uitschijnen dat interfaces eigenlijk onnodig zijn.

Interfaces zijn nodig als MI niet ondersteund wordt. Ze zijn niets meer dan syntactische suiker als MI wel ondersteund wordt (zie ook de laatste alinea in .oisyn in "[JAVA] Implementen van een Interface d.m..."). Syntactische suiker waarvan ik het nut dus niet helemaal begrijp (en dat is waarover we aan het discussieren waren)

Wat ik probeer aan te geven is dat de enige reden waarom java en .net een echt verschil kennen tussen classes en interfaces is omdat MI niet ondersteund wordt. Een class kan niet meerdere andere classes overerven, maar dat zou betekenen dat een interface als IList ook niet geimplementeerd kan worden als je klasse al overerft van een andere klasse. Er is dus gekozen voor een duidelijke scheiding, aan de ene kant classes die je kunt overerven en die mogelijk een implementatie hebben, en aan de andere kant de echte interfaces die alleen methoden definieren zonder implementatie. In feite doe je dus wel multiple inheritance, zonder de mogelijke problemen van cyclic inheritance en het hebben van implementaties van dezelfde methode door meerdere superclasses. Ik zou het dus niets anders willen noemen dan een workaraound, want door MI volledig te ondersteunen valt het nut van aparte interface types weg. En ja, dan is het de taak van de ontwerper om te zorgen dat iets dat geen implementatie behoort te hebben ook daadwerkelijk geen implementatie krijgt, maar dat is gewoon een extra verantwoordelijkheid die je als ontwerper meekrijgt. Een verantwoordelijkheid die de ontwerper toch al een beetje had, aangezien hij in een SI taal ook had kunnen kiezen voor een abstracte class. Het enige verschil is dat ie nu wet meer mogelijkheden heeft, en dat een ontwerpfout niet zo destrastreus is in een SI taal

[.oisyn]

Verwijderd schreef op 17 juni 2004 @ 14:58:
(Aan MI zitten natuurlijk wel haken en ogen. Een vreemde cotcha is bv dat de volgorde van de base classes uitmaakt in je classe definitie: Je kunt van een object die MI gebruikt alleen van de eerste base class een pointer to member function nemen.)

Dat is niet waar:

C++:

struct A { virtual void a (); };
struct B { virtual void b (); };
struct C : public A, public B { };


void (C::*a) () = &C::a;
void (C::*b) () = &C::b;

.edit: uitgebreider voorbeeld:

C++:

struct A { virtual void a (); };
struct B { virtual void b (); int i; };
struct C : public A, public B { };

int C::* ci = &C::i;
int B::* bi = &B::i;

void (C::* cb) () = &C::b;
void (B::* bb) () = &B::b;

void f ()
{
    C c;
    c.*ci = 4;
    c.*bi = 34;

    (c.*cb) ();
    (c.*bb) ();
}

Compileert natuurlijk allemaal prima (anders zei ik het niet )

[ Voor 38% gewijzigd door .oisyn op 17-06-2004 15:30 ]

[.oisyn]

Alarmnummer schreef op 17 juni 2004 @ 15:02:
Maar hoe vaak gebruik jij multiple inheritance terwijl je beter een delegate (inner class die die interface/abstract class implementeerd/extend)? Het gebeurt me al niet eens vaak meer dat een class meerdere interfaces implementeerd

C++ ondersteunt helaas geen inner classes (je kunt natuurlijk wel een class definieren in een class definitie, maar dat is simpelweg een namespace iets; het is zeg maar gelijk aan een static class definitie in een Java class). Je hebt gelijk dat echte MI verder vrij zeldzaam is, maar een vaak gebruikt voorbeeld is bijvoorbeeld de TeleFax. Je hebt een interface Apparaat met een methode neemOp (), 2 classes Telefoon en Fax die Apparaat implementeren, en een class die beide samenvoegt: de TeleFax. De TeleFax kijkt bij een neemOp of het om een gewoon telefoongesprek of een fax gaat, en roept aan de hand daarvan de methode van de juiste baseclass aan.

En ja, natuurlijk kun je dat oplossen door een TeleFax geen subclass te maken van Telefoon en Fax maar alleen Apparaat te implementeren, en dan gewoon 2 private members telefoon en fax te definieren aan wie je de call gaat doorsluizen. Feit is dat dat een workaround is (als iets een Telefoon verwacht kun je geen TeleFax meer geven), en dat alles wel op een bepaalde manier op te lossen is bij gemis aan features. Dat neemt niet weg dat MI in sommige gevallen gewoon erg handig is, ook al komen ze niet vaak voor.

[ Voor 3% gewijzigd door .oisyn op 17-06-2004 15:21 ]

[Verwijderd]

whoami schreef op 17 juni 2004 @ 14:40:
[...]

Idd, iemand kan aan die interface definitie foefelen, maar, als je een goeie programmeur bent, dan roep je je member methods aan via een interface-instantie.
Als je dan die method aanroept, dan zal de compiler gaan klagen:

code:

void DoSomething( IMyInterface miep )
{
     miep.Process ();   // stel dat jij process uit de IMyInterface hebt gehaald, 
                         // dan compiled dit niet.
}

Het voorbeeld van jou klopt inderdaad als je functies weghaald uit de interface. Mischien ook wel handig om op te merken dat je bij het toevoegen of veranderen van functies nog niet eens een call hoeft te doen om een compiler fout te krijgen in java.

Niet als die class in C++ die je interface moet voorstellen alle methods als abstract heeft gedefinieerd.

Maar dat is nu juist de stelling. Iemand linkt jouw class met een onbedoeld veranderde interface (mischien een nieuwe versie van een lib), en er komt geen compiler fout maar wel veranderd gedrag.

bv

C++:

class IFoo {
    public: virtual void doIt() = 0;
};

class FooImpl : public IFoo {

    public: void doIt() {
        std::cout << "We doen het in de implementatie" << std::endl;
    }
};


int main () { 

    
    IFoo* myIFoo = new FooImpl;

    myIFoo->doIt(); // prints : "We doen het in de implementatie"

    return 0;
}

Stel nu voor dat een onverlaat de interface veranderd: virtual wordt weggehaald en de methode krijgt een implementatie:

C++:

class IFoo {
    public: void doIt() {
        std::cout << "We doen het in de interface" << std::endl;
    }
};

class FooImpl : public IFoo {

    public: void doIt() {
        std::cout << "We doen het in de implementatie" << std::endl;
    }
};


int main () { 

    
    IFoo* myIFoo = new FooImpl;

    myIFoo->doIt(); // prints: "We doen het in de interface"

    return 0;
}

Slechte zaak: Geen compiler fout, niet eens een warning, maar wel veranderd gedrag. Wie is hier de schuldige? De maker van FooImpl? De maker van IFoo? Degene die een verkeerde versie van FooImpl met een verkeerde versie van IFoo linked? Stroustrup zelf?

Ik zou zeggen de maker van IFoo, omdat die zijn afspraken opeens niet meer nakomt.

Dit zou ophetzelfde neerkomen als eerst:

Java:

public interface INice {
    public void doSomethingNice();
}

public class NiceImpl implements INice {
    public void doSomethingNice() {
        // do something nice indeed
    }
}

En dan later opeens:

Java:

public interface INice {
    public void doSomethingNice();
}

public class NiceImpl implements INice {
    public void doSomethingNice() {
        // actually do something very bad now
    }
}

De implementatie doet nu iets anders als het contract voorschreef. De implementor is nu fout.

[Verwijderd]

whoami schreef op 17 juni 2004 @ 14:47:
Dit vond ik net:

[... Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface. ... ]

En dat is dus de reden waarom een C++ interface zonder een apart keyword nodig te hebben exact hetzelfde is als in Java. Zowel in Java als in C++ zou je een interface (contract) niet moeten veranderen nadat deze is opgesteld. Met een echt contract verwacht je ook dat de trouw van beide kanten komt, en niet alleen van diegene die het moet uitvoeren.

[whoami]

.oisyn schreef op 17 juni 2004 @ 15:20:
[...]


En ja, natuurlijk kun je dat oplossen door een TeleFax geen subclass te maken van Telefoon en Fax maar alleen Apparaat te implementeren, en dan gewoon 2 private members telefoon en fax te definieren aan wie je de call gaat doorsluizen. Feit is dat dat een workaround is (als iets een Telefoon verwacht kun je geen TeleFax meer geven), en dat alles wel op een bepaalde manier op te lossen is bij gemis aan features. Dat neemt niet weg dat MI in sommige gevallen gewoon erg handig is, ook al komen ze niet vaak voor.

Is het een workaround om die Telefax dmv compositie v/e object Telefoon en een object Fax te maken ?
Ik denk het niet. Je zou op die manier misschien zelfs een veel onderhoudbaarder geheel hebben.
Daarnaast zou je in dit geval misschien wel een soort van strategy-pattern kunnen gebruiken: om er nog maar eens OO stellingen bij te sleuren:
- favor composition over inheritance

[Alarmnummer]

whoami schreef op 17 juni 2004 @ 15:38:
[...]


Is het een workaround om die Telefax dmv compositie v/e object Telefoon en een object Fax te maken ?

Het is zeker geen workaround want dat is namelijk hetzelfde als die delegate oplossing. Alleen kan ik met een interne class bij de ingewanden komen van de omsluitende class en dat kan je met een normale class niet.

[.oisyn]

whoami schreef op 17 juni 2004 @ 15:38:

Is het een workaround om die Telefax dmv compositie v/e object Telefoon en een object Fax te maken ?

ja, want een TeleFax is_a Telefoon. Op jouw manier is dat niet zo. Als Kees tegen mij zegt: "doe mij eens een telefoon, dan kan ik bellen", dan kan ik hem een TeleFax geven. Hij kan eveneens zeggen "en geef me nu eens de fax, want ik moet wat faxen". Dan geef ik 'm diezelfde TeleFax.
In programmacode heb je dus 2 functies, eentje die een Telefoon accepteert, en eentje die een TeleFax accepteert. Maar geen van de 2 functies kan ik aanroepen door gewoon de TeleFax als parameter te geven. Daar is wel weer omheen te werken (zoals altijd) door een getTelefoon () op te nemen in de TeleFax die z'n telefoon instantie terug geeft, maar dat klopt toch niet met de werkelijkheid? Ik ga toch ook geen TeleFax uit elkaar slopen omdat Kees alleen maar wil bellen, en niet wil faxen?

Kan ook wel weer opgelost worden: je maakt van Telefoon, Fax en TeleFax interfaces, en classes TelefoonImpl, FaxImpl en TeleFaxImpl die die interfaces implementeren. Je TeleFaxImpl laat je alle interfaces inheriten, en hij gebruikt intern de objecten TelefoonImpl en FaxImpl. Je gaat echter aan het punt voorbij dat het allemaal workarounds blijven voor features die je niet tot je beschikking hebt. Je kan ook gewoon MI gebruiken, dan hoef je al die moeite met interfaces en implementaties niet eens te doen.

Bovendien zijn veel patterns juist uitgevonden om om bepaalde dingen heen te werken. Denk je ook niet dat zowel jij als Alarmnummer het composiet pattern vaak gebruiken juist omdat je geen MI tot je beschikking hebt? Net als dat visitors gebruikt worden bij gebrek aan multidispatch? Net als dat het state pattern gebruikt wordt bij gebrek aan statemachine constructies in de taal zelf? Ik noem maar een paar voorbeelden

[ Voor 34% gewijzigd door .oisyn op 17-06-2004 15:58 ]

[whoami]

.oisyn schreef op 17 juni 2004 @ 15:43:
[...]


ja, want een TeleFax is_a Telefoon.

Hmm, een TeleFax kan ook een telefoon en een fax hebben.
Net zoals je kunt zeggen dat een Window in Windows een Rectangle heeft waarop hij z'n 'dingen' toont, en niet noodzakelijk een Rectangle is.
Sterker zelfs, door een Window een member van het type Shape te geven, zou je in principe ook Windows moeten kunnen hebben die cirkels, driehoeken, .... zijn.

[ Voor 21% gewijzigd door whoami op 17-06-2004 15:51 ]

[.oisyn]

(heb m'n vorige post trouwens geedit)

Dat vind ik een beetje een dom voorbeeld, een Window is namelijk helemaal geen Rectangle, en bovendien toont hij z'n dingen niet op een rectangle, maar op het scherm (een rectangle is niets meer dan een positie en een grootte), en de vraag is of ie er ook daadwerkelijk wel een heeft. Het hebben van een rectangle is namelijk niet een essentieel iets voor een Window, hij kan prima werken zonder dat ie weet waar ie zich bevindt. Het is puur voor het OS van belang om te bepalen waar de window getekend moet worden, en wanneer hij mouse events moet sturen naar de window. Daarnaast is een Rectangle gewoon een data-type, het heeft geen methoden en dus geen implementatie.

En een WerkNemer is toch ook een Persoon? Hij heeft toch geen Persoon? Waarom zou het voor een apparaat als een telefax ineens anders zijn? Het is hetzelfde ding, het kan alleen meer. Net als dat een WerkNemer meer kan

[ Voor 6% gewijzigd door .oisyn op 17-06-2004 15:56 ]

[Verwijderd]

.oisyn schreef op 17 juni 2004 @ 15:11:

Dat is niet waar:

[...]

Compileert natuurlijk allemaal prima (anders zei ik het niet )

Ik bedoelde een iets andere situatie waarbij je de pointer to member functions op een pointer naar een base class toepast. Dus:

C++:

#include <iostream>

struct A { virtual void a () { std::cout << "A"; }; };
struct B { virtual void b () { std::cout << "B"; }; };

struct C : public A, public B { 
    virtual void a () { std::cout << "AC"; };
    virtual void b () { std::cout << "BC"; };
};

typedef void(A::* FuncA)(void);
typedef void(B::* FuncB)(void);

int main() {
    FuncA funcA = &A::a;
    FuncB funcB = &B::b;
    
    A* cA = new C;    
    (cA->*funcA) ();

    B* cB = new C;
    (cB->*funcB) ();

    return 0;
}

Ik probeerde het net even met VS 7.1 en het werkt!

Ik weet echter vrij zeker dat het niet werkte met VS 7.0 (die ik nu helaas niet installed heb). In mijn developper 'dagboek' van het project waar ik toen aan werkte heb ik er zelfs nog een aantekening over gemaakt. Ik kan me vaagjes iets herinneren dat het ook een expliciete compiler foutmelding gaf, iets in de trend van "can only apply pointer to member to first base" of iets in die richting. Of ik ben gek Dat kan natuurlijk ook...

[whoami]

.oisyn schreef op 17 juni 2004 @ 15:43:
[...]

Bovendien zijn veel patterns juist uitgevonden om om bepaalde dingen heen te werken. Denk je ook niet dat zowel jij als Alarmnummer het composiet pattern vaak gebruiken juist omdat je geen MI tot je beschikking hebt?

Hmm, die patterns zijn niet ontworpen met het oog op talen die geen MI hebben. Ze zijn dus ook niet opgesteld als 'work-around' voor MI.
Sterker zelfs, het GoF boek is uitgebracht in '94 dacht ik; van Java en C#was er toen nog geen sprake. De code-voorbeelden zijn dan ook in C++, waar je dus wel MI hebt.

[whoami]

.oisyn schreef op 17 juni 2004 @ 15:56:
En een WerkNemer is toch ook een Persoon? Hij heeft toch geen Persoon? Waarom zou het voor een apparaat als een telefax ineens anders zijn? Het is hetzelfde ding, het kan alleen meer. Net als dat een WerkNemer meer kan

Het Window was misschien een dom voorbeeld;
Echter, in bovenstaand voorbeeld van jou ga je inderdaad een Werknemer van Persoon inheriten. Hier zou het dom zijn om mbhv composition te werken.
Composition ga je gebruiken als een bepaald iets op een andere manier kan geimplementeerd worden.

Je hebt bv. een abstracte class (of een interface) 'Dier', daar ga je classes 'Vogel', Paard, Vis van inheriten.
Ieder dier kan zich voortbewegen, maar dat gaat voor ieder dier op een andere manier gebeuren. Hier kan je dus een abstracte class of interface 'Mouvement' voor gebruiken; een dier heeft dan een instance van mouvement.
Voor een vogel zal dat 'Vliegen' zijn, voor een vis zwemmen, etc...

[Alarmnummer]

whoami schreef op 17 juni 2004 @ 16:21:
[...]
Je hebt bv. een abstracte class (of een interface) 'Dier', daar ga je classes 'Vogel', Paard, Vis van inheriten.
Ieder dier kan zich voortbewegen, maar dat gaat voor ieder dier op een andere manier gebeuren. Hier kan je dus een abstracte class of interface 'Mouvement' voor gebruiken; een dier heeft dan een instance van mouvement.
Voor een vogel zal dat 'Vliegen' zijn, voor een vis zwemmen, etc...

Precies.

Het probleem is dat je met extenden dan helemaal ondersneeuwt in alle subclasses VliegenVogel, ZwemmendeVogel, LopendeVogel, ZwemmendeVis,KruipendeVis,VLiegendeVis.

En het gaat helemaal lachen worden als je ook weer combinaties gaat krijgen, bv een werknemer die directeur is en personeelsmanager. Je krijgt dan een ware class explosie en dan is het een stuk praktisch om het met een compostie op te lossen.

code:

class Persoon{
     Set<Rol> getRollen(){...}
}

interface Rol{
     void werk(Persoon p);
}

class Personeelsmanager implements Rol{
      void werk(Persoon p){... ontsla ze allemaal}
}

class Directeur implements Rol{
     void werk(Persoon p){...}
}

[ Voor 3% gewijzigd door Alarmnummer op 17-06-2004 16:37 ]

[.oisyn]

Verwijderd schreef op 17 juni 2004 @ 16:13:
Ik weet echter vrij zeker dat het niet werkte met VS 7.0 (die ik nu helaas niet installed heb). In mijn developper 'dagboek' van het project waar ik toen aan werkte heb ik er zelfs nog een aantekening over gemaakt. Ik kan me vaagjes iets herinneren dat het ook een expliciete compiler foutmelding gaf, iets in de trend van "can only apply pointer to member to first base" of iets in die richting. Of ik ben gek Dat kan natuurlijk ook...

Dan ligt het natuurlijk aan de compiler, en niet zozeer aan de C++ standaard. Om te controleren of iets zou moeten werken gebruik ik altijd de online testversie van comeau. Als Comeau het niet accepteert weet je vrijwel zeker dat het niet mag volgens de standaard

[Verwijderd]

curry684 schreef op 17 juni 2004 @ 01:50:
[...]

Ik zei al dat het (D)COM was, wat door VB, Java (!), C++, .NET en weet ik het wat gebruikt kan worden. Het ging me echter enkel om het principe, dit kun je in Java namelijk ook implementeren.

Echter, het is namelijk wederom een ranzige workaround om iets dat je in OOP gewoon niet moet willen: service without contract. Maar minder ranzig dan bytecode alteration.

Service without contract?
Wat als dat spreekwoordelijke contract er wel is, maar onzichtbaar is voor een applicatie?

[...]

COM in het algemeen wordt dan ook door de hele wereld (incluis Microsoft) gezien als Microsoft's stomste fout ooit.

Mja, dat geloof ik best, maar waar ik het over heb maakt wat mij betreft geen deel uit van die fout.

[Verwijderd]

btw beste Cybarite, ik weet dat het moeilijk is om alle berichten en code examples te doorlezen (het zijn er nogal veel geworden), maar je hebt de volgende vraag nog steeds niet beandwoord:

Is reinterpret_cast niet gewoon waarna je op zoek was in java?

[Verwijderd]

Verwijderd schreef op 17 juni 2004 @ 17:39:
btw beste Cybarite, ik weet dat het moeilijk is om alle berichten en code examples te doorlezen (het zijn er nogal veel geworden), maar je hebt de volgende vraag nog steeds niet beandwoord:

Is reinterpret_cast niet gewoon waarna je op zoek was in java?

Ik heb zojuist de nieuwe posts doorgelezen, maar die zijn allemaal ietwat offtopic.

Ik kan weinig casten, aangezien ik een Interface implement, en geen abstract class extend. Verder zou ik niet weten hoe ik een reinterpret_cast kan uitvoeren als ik het over het implementen van een Interface heb...

Ik kan gewoon totaal geen operaties uitvoeren op een geimplemente Interface...

Met een abstract class zou ik dat misschien nog wel kunnen doen (er vanuit gaande dat 'super' kunstmatig niet werkt bij het implementen van Interfaces); reinterpret_cast(super); .
Als iets in die geest uberhaupt al kan lijkt dit me vrij linke soep...

edit:
Maar wil iedereen proberen bij Java te blijven want van C/C++/.Net/etc heb ik weinig kaas gegeten, en of het daar wel of niet kan is irrelevant voor de taal Java.

[ Voor 13% gewijzigd door Verwijderd op 17-06-2004 18:04 . Reden: toevoeging ]

[.oisyn]

henk_DE_man: Volgens mij niet, en wat heeft ie daar überhaupt aan dan? In C++ gaat zoiets ook niet werken; de reden waarom jouw voorbeeld werkt is omdat de compiler de types kent, en dus ook wat je dynamic_reinterpret_cast returnt. De compiler weet dus welke test () aangeroepen moet worden, omdat het type bekend is.

Wat Cybarite wil is het volgende:

C++:

// de interface die geimplementeerd moet worden, alleen bekend door Cybarite,
// niet door de compiler
class MyInterface
{
public:
    virtual void func1 () = 0;
    virtual void func2 () = 0;
};

// de daadwerkelijke implementatie
class MyClass
{
public:
    virtual void func1 () { std::cout << "MyClass::func1 ()" << std::endl; }
    virtual void func2 () { std::cout << "MyClass::func2 ()" << std::endl; }
};

MyInterface * convertToInterface (MyClass * pClass)
{
    // wat nu? Als je mazzel hebt werkt een reinterpret_cast,
    // maar alleen als de vtables exact overeenkomen
}

Wat hier moet gebeuren is het aanmaken van een proxy, die MyInterface implementeert en de calls doorsluist naar een MyClass.

Waarom Cybarite dit probleem heeft is me niet helemaal duidelijk, maar ik heb een vermoeden dat MyClass een soort van plugin is die via een classloader wordt ingeladen. En bij het implementeren van de plugin heeft hij geen beschikking over de interfaces die geimplementeerd moeten worden (maar als persoon heeft ie er natuurlijk wel kennis over). Ik denk dat een oplossing door een Proxy toch het beste is. Wat hij dan wel moet doen is zorgen dat MyClass een InvocationHandler implementeert (hetzelfde als de IDispatch waar curry het over had), en dus in de invoke () methode de calls doorsluist naar de juiste methode. Op die manier is bij het implementeren van MyClass de MyInstance niet nodig. InvokeHandler natuurlijk wel, maar dat is een standaard java klasse en dat moet dus geen probleem zijn lijkt me. En als dat wel een probleem is dan heeft ie vet pech, want dan is er gewoon geen oplossing zonder byte-code generation

[ Voor 39% gewijzigd door .oisyn op 17-06-2004 18:14 ]

[Verwijderd]

.oisyn heeft het wel door denk ik.

Zou je:

C++:

MyInterface * convertToInterface (MyClass * pClass) 

Even uit kunnen leggen, is namelijk vrij cruciaal wil ik verzekerd zijn dat jij/andere C'ers het goed begrijpen.

Wat ik begrijp is dat er wat gerotzooid wordt met pointers in die code?
Maar is deze syntax denkbeeldig of werkt dit echt?
Het komt op mijn nl. een beetje onbekend over, maar ja ik heb nog geen C compiler aangeraakt (met eigen code dan) ....