[PHP5] private interface methodes

[aex351]

PHP:

interface tester {
private function mijnFunctie($string) ; 
}

class woei implements tester {
private function mijnFunctie($string) {
  echo 'werkt niet '; 
}
}

is het het mogelijk om in php5 te werkten met private / protected interfaces. Alles wat ik probeer levert een fatale foutmelding op. Verder kan ik er geen informatie over vinden, lijkt wel als niemand dit probleem heeft.

public werkt overigens wel prima

[ Voor 9% gewijzigd door aex351 op 07-05-2006 01:00 ]

[momania]

private lijkt mij sowieso niet te werken... (in java is private iig echt private, dus ook niet toegankelijk voor afgeleiden)
protected zou dan de juiste scope moeten zijn voor method overriding

hoe dat in php echter is geregeld weet ik niet.

[Verwijderd]

Wat is het nut van een private method aan een interface? Het idee van een interface is dat je gegevens kunt verstrekken aan andere classes, over wat classes die de interface implementeren allemaal kunnen? Wat hebben die classes eraan om iets over een method te weten die ze niet kunnen aanroepen?

[aex351]

met private kunnen andere klassen via extenden er alsnog gebruik van maken. Via interfaces probeer ik het gewoon in de hand te houden, ook handig voor api's enz.

[Verwijderd]

aex351 schreef op zondag 07 mei 2006 @ 01:11:
met private kunnen andere klassen via extenden er alsnog gebruik van maken

Dat zou niet moeten. Private betekent echt private. Alleen voor de class zelf dus. Voor classes die de class extenden is er protected. Of het moet in PHP nog rotter geimplementeerd zijn dan ik dacht.

[momania]

aex351 schreef op zondag 07 mei 2006 @ 01:11:
met private kunnen andere klassen via extenden er alsnog gebruik van maken. Via interfaces probeer ik het gewoon in de hand te houden, ook handig voor api's enz.

Het idee van een interface is dat het dient als een public descriptor.. alles dient dus public te zijn
Anders heb je er niks aan. Want hoe zou je van een interface die je wilt gebruiken dan de methods willen aanroepen?

Als je wilt dat bepaalde implementaties bepaalde methods verplicht moeten implementeren, dan moet je naar een abstracte superclass kijken en niet naar interfaces Alleen weet ik niet of php abstracte classes support.

[ Voor 32% gewijzigd door momania op 07-05-2006 01:16 ]

[NMe]

Nee, PHP heeft daar inderdaad gewoon protected voor. Private is netjes ècht private, zoals het hoort.

[aex351]

Verwijderd schreef op zondag 07 mei 2006 @ 01:13:
[...]

Dat zou niet moeten. Private betekent echt private. Alleen voor de class zelf dus. Voor classes die de class extenden is er protected. Of het moet in PHP nog rotter geimplementeerd zijn dan ik dacht.

ok mijn fout. dacht even dat private en protected precies anders om waren. ik bedoel dus protected, maar dat werkt ook niet.

[ Voor 3% gewijzigd door aex351 op 07-05-2006 01:16 ]

[prototype]

aex351 schreef op zondag 07 mei 2006 @ 01:16:
[...]

ok mijn fout. dacht even dat private en protected precies anders om waren. ik bedoel dus protected, maar dat werkt ook niet.

Erm, besef je uberhaupt wel waar je interfaces voor gebruikt? Zoals momania al zei dient een interface als public descriptor; het specificeert methoden, waar een programmeur tegenaan programmeert. Dat protected en private niet kunnen is maar goed ook, omdat dat niet de bedoeling is van een interface. Die visibility modifiers zijn veel meer implementatie gebonden dan specificatiegebonden.

[NMe]

Aangezien je private en protected door elkaar haalt: kan het niet zijn dat je interfaces en abstracte klasses ook door elkaar aan het halen bent? Wat jij wil kan namelijk wel met een abstracte klasse.

[aex351]

-NMe- schreef op zondag 07 mei 2006 @ 01:26:
Aangezien je private en protected door elkaar haalt: kan het niet zijn dat je interfaces en abstracte klasses ook door elkaar aan het halen bent? Wat jij wil kan namelijk wel met een abstracte klasse.

Is mogelijk dat ik het met abstracte klassen ook kan oplossen. Ik zal even wat meer uitleggen waarom ik gebruik maak van interfaces.

klasse A : maakt een object van klasse B (adapter - mysql.php / mssql.php) . De functies/methodes in klasse A zijn gelijk aan die van klasse B op het punt na dat klasse B de "echte" mysql/mssql/oracle code bevat voor het uitvoeren ervan. Dit word aangeroepen via klasse A , maar klasse A geeft alleen maar true/false terug gebasseerd op uitvoer van klasse B.

Nu het meer uniform te maken dacht ik aan interfaces voor klasse B. Maar omdat ik sommige functies protected wil hebben in klasse B lukt dit niet.

Is een beetje een denkertje

[ Voor 3% gewijzigd door aex351 op 07-05-2006 01:33 ]

[NMe]

Ik volg je niet helemaal zo op de late avond, maar naar wat ik van je verhaal begrijp kun je inderdaad eens naar abstracte klassen kijken als je graag vooraf je protected functies vast wil leggen.

[prototype]

aex351 schreef op zondag 07 mei 2006 @ 01:33:
[...]

Is mogelijk dat ik het met abstracte klassen ook kan oplossen. Ik zal even wat meer uitleggen waarom ik gebruik maak van interfaces.

klasse A : maakt een object van klasse B (adapter - mysql.php / mssql.php) . De functies/methodes in klasse A zijn gelijk aan die van klasse B op het punt na dat klasse B de "echte" mysql/mssql/oracle code bevat voor het uitvoeren ervan. Dit word aangeroepen via klasse A , maar klasse A geeft alleen maar true/false terug gebasseerd op uitvoer van klasse B.

Nu het meer uniform te maken dacht ik aan interfaces voor klasse B. Maar omdat ik sommige functies protected wil hebben in klasse B lukt dit niet.

Is een beetje een denkertje

De relatie tussen klasse A en B is dan whole-part, waarbij klasse A een instantie van B aggregeert. De methoden van A delegeren vervolgens dan aan B. Je interface moet dan alleen de publieke methoden specificeren waar A naar B delegeert. Protected members zijn alleen zichtbaar voor B en zijn subklassen. A heeft hier geen zicht op.

[momania]

class A moet iets doen met class B, maar mag niet weten hoe class B eruit ziet of zelf class B aanmaken en aanroepen? is dat wat je wilt?

Dan zou je voor class B (de implementatie) idd een interface kunnen hangen. En die kan je middels een factory vanuit class A laten aanmaken.

een factory method iets als createB() geeft dan als resultaat de interface terug om mee te werken, maar is uiteindelijk een implementatie van B

even in java:

Java:

class Factory {
  public InterfaceName createClassB() {
    return new B();
  }
}

Java:

class A {
  public void doeIets() {
    Factory fac = new Factory();
    
    InterfaceName x = fac.createB();
    x.doeMoeilijkeMySQLDingenEtc();
  }
}

[prototype]

momania schreef op zondag 07 mei 2006 @ 01:41:
class A moet iets doen met class B, maar mag niet weten hoe class B eruit ziet of zelf class B aanmaken en aanroepen? is dat wat je wilt?

Dan zou je voor class B (de implementatie) idd een interface kunnen hangen. En die kan je middels een factory vanuit class A laten aanmaken.

een factory method iets als createB() geeft dan als resultaat de interface terug om mee te werken, maar is uiteindelijk een implementatie van B

even in java:

Java:

class Factory {
  public InterfaceName createClassB() {
    return new B();
  }
}

Java:

class A {
  public void doeIets() {
    Factory fac = new Factory();
    
    InterfaceName x = fac.createB();
    x.doeMoeilijkeMySQLDingenEtc();
  }
}

Een eis is dus dat de methoden via A geinvoked worden, dus factory gaat niet op?

[edit]
Mjah, opzich kan dat ook, beetje vage omschrijving van TS mbt de levensduur van de objecten.

[ Voor 7% gewijzigd door prototype op 07-05-2006 01:45 ]

[momania]

prototype schreef op zondag 07 mei 2006 @ 01:44:
[...]


Een eis is dus dat de methoden via A geinvoked worden, dus factory gaat niet op?

[edit]
Mjah, opzich kan dat ook, beetje vage omschrijving van TS mbt de levensduur van de objecten.

idd vage omschrijving... misschien is de TS meer opzoek naar encapsulation?