[JAVA] Implementatie probleem

[eghie]

Ik ben bezig met een software distributie systeempje te maken in JAVA. Ben nu bezig met de server. Nu heeft deze server een aantal settings. Deze settings moeten uit een config bestandje worden gehaald. Nu wil ik het zo ontwerpen:

Ik heb een settings classe, ongeveer zoiets:

Settings

Server : ServerSettings Client : ClientSettings Log : LogSettings

getInstance() : Settings loadSettings() : void

Deze classe is een singleton (heb cloning ook geblokkeerd). Deze classe laad instellingen uit een config file en zet ze in de juiste subclasse en variablen. Die instellingen laden doe ik dmv de loadSettings() methode, die private is en die wordt aangeroepen in de private constructor (singleton remember). Ik heb deze classe in subclasses opgedeeld om wat overzicht te creeeren.

Dit is een voorbeeld van zo'n subclasse, ServerSettings:

ServerSettings

ServerName : String ListenInterface : Interface PortNr : Integer

Nu wil ik dit door de hele applicatie kunnen aanroepen door:

Java:

Settings.getInstance().Server.PortNr

Allemaal heel leuk en aardig, maar als ik dit zo doe kun je in de hele applicatie ook die waarden veranderen, ik wil dat echter niet toestaan. Ik wil dus zorgen dat je in de hele applicatie die waarden niet kan veranderen, maar dat ze wel geset kunnen worden door de Settings classe.

De vraag is nu, hoe implementeer ik dit? Het kan wezen dat ik te moeilijk denk, vandaag met gemak al teveel gedaan, maar ik kan er maar niet opkomen.

Ik heb naar final gekeken, maar die kun je geloof ik niet zelf setten, dus dat is geloof ik geen oplossing.

[Varienaja]

Maak een getter voor server en poortnummer. Deze getter is dan public. De variabelen zelf moeten dan private worden.

[pjvandesande]

Java ondersteund geen properties, of ondertussen wel?

Maargoed, ik ga nog even uit van niet. Je maakt dan toch gewoon methods zoals GetPortNummer, GetServerName etc.

Deze geven gewoon een private member terug. Deze private member is dus gewoon te bereiken door de eigen class en zo kunnen door de LoadSettings method gewoon geset worden.

offtopic:
Traag!

[ Voor 11% gewijzigd door pjvandesande op 03-11-2005 16:38 ]

[eghie]

questa schreef op donderdag 03 november 2005 @ 16:37:
Java ondersteund geen properties, of ondertussen wel?

Maargoed, ik ga nog even uit van niet. Je maakt dan toch gewoon methods zoals GetPortNummer, GetServerName etc.

Deze geven gewoon een private member terug. Deze private member is dus gewoon te bereiken door de eigen class en zo kunnen door de LoadSettings method gewoon geset worden.

offtopic:
Traag!

Hmm, hier had ik dus nog niet aan gedacht Damn, ben nog een beetje slaperig

JAVA ondersteund inderdaad nog geen getters en setters, wel jammer overigens, vind ze namelijk wel fijn.

[Robtimus]

offtopic:
Please dear Primus, wat een verschrikkelijk hoofdlettergebruik in dit topic

Maar getters (en setters) zijn altijd the way to go in OO programmeren.

[Robtimus]

eghie schreef op donderdag 03 november 2005 @ 18:48:
JAVA ondersteund inderdaad nog geen getters en setters, wel jammer overigens, vind ze namelijk wel fijn.

Eh? Je bedoelt properties zoals in VB of Delphi? Nee dat niet nee. Maar wat zijn getVariable() en setVariable() dan? Juist, een getter en setter.

[eghie]

IceManX schreef op donderdag 03 november 2005 @ 21:47:
[...]
Eh? Je bedoelt properties zoals in VB of Delphi? Nee dat niet nee. Maar wat zijn getVariable() en setVariable() dan? Juist, een getter en setter.

Ik bedoel die getters en setters zoals in C# en VB.NET (van C# vind ik ze net iets fijner), dus properties ja. Over VB en Delphi aan getters en setters kan ik niet echt mee praten.

getVariable() en setVariable() zijn eigenlijk gewoon methodes en functies, dus dat bedoelde ik niet echt.

IceManX schreef op donderdag 03 november 2005 @ 21:46:

offtopic:
Please dear Primus, wat een verschrikkelijk hoofdlettergebruik in dit topic

Maar getters (en setters) zijn altijd the way to go in OO programmeren.

offtopic:
Wat vind je irritant aan het hoofdletter gebruik? Dan zal ik wat proberen te minderen

[Alarmnummer]

Ik zou een beetje oppassen met het gebruik van singletons. Als een object bepaalde dependencies heeft, dan injecteer ik het gewoon in dat object en laat ik object niet zoeken naar de singleton waar de informatie in staat. Het voordeel is dat je oa veel beter testbare code krijgt, maar ook dat je veel herbruikbare code krijgt omdat je tot in de kleinste details kunt controleren wat erin gaat.

Ik ben zelf tot deze ontdekking gekomen sinds ik Spring gebruik, maar heb intussen ook ingezien dat mijn manier van werken totaal is veranderd, zonder het gebruik van Spring. Wat ik zou doen is eerst proberen te functionaliteiten proberen te scheiden. Jouw ServerProperies hebben 2 functionaliteiten:
1) laden van properties
2) opslagcontainer voor properties.
Op het moment dat jij je properties ergens anders vandaan wilt laten komen (bv een database), of als je dezelfde class wilt gebruiken voor verschillende instanties, dan kom je zwaar in de problemen.

Daarom probeer ik functionaliteiten van classes dus te scheiden.

In pseudecode zou ik het als volgt aanpakken:
ServerConfig serverConfig = ServerConfigPropertiesFileLoader.load(''some.file");
Server server = new Server(serverConfig);

Op deze manier kan je bv ServerConfig hergebruiken zonder dat je vast zit aan het properties bestand. Je zou bv ook kunnen zeggen:

ServerConfig serverConfig = ServerConfigDatabaseLoader.loadRecord(1);
Server server = new Server(serverConfig);

En dan de singletons. Met de singletons heb je gewoon een groot probleem dat je niet onder die instantie uit komt. Singletons zijn denk ik wel het meest gebruikte design pattern en in 99% van de gevallen zorgen ze voor grote problemen binnen een ontwerp.

Stel dat ik jouw service op 2 poorten zou willen aanbieden? Hoe zou ik dat moeten doen?? Dat gaat dus niet lukken met een Singleton. Wel als je het geen singleton maakt.

vb:

ServerConfig serverConfig1 = ServerConfigPropertiesFileLoader.load(''some.file");
Server server1 = new Server(serverConfig1);
ServerConfig serverConfig2 = ServerConfigPropertiesFileLoader.load(''someother.file");
Server server2 = new Server(serverConfig2);

Op deze manier krijg je niet van die stijve ontwerpen. In 99% van de gevallen zijn Singletons bad bad bad.

En ander belangrijk concept is dat je moet werken met layers/rings. In jouw geval heb je bepaalde core functionaliteit dat toegepast kan worden in een lokale maar ook in een remote omgeving. Het remote gedeelte zit als een ring om het lokale gedeelte heen. Stel dat je een bepaalde (lokale) dienst heb die je remote wilt maken (weer via die 2 poorten).

LocalService localService = new LocalService(....);
ServerConfig serverConfig1 = ServerConfigPropertiesFileLoader.load(''some.file");
RemoteServer server1 = new RMIRemoteServer(serverConfig1,localService);
ServerConfig serverConfig2 = ServerConfigPropertiesFileLoader.load(''someother.file");
RemoteServer server2 = new RMIRemoteServer(serverConfig2,localService);

Op deze manier kan je de localService delen tussen 2 verschillende remote service interfaces. Het voordeel hiervan is dat hele hele remoting aspect niet zo`n gruwelijke invloed krijgt op je design. Je kan bv dezelfde LocalService delen met een webinterface, met een RMI service en met een Hessian Service. Het is ineens geen onderdeel meer van je architectuur, maar een implementatie detail.

[ Voor 53% gewijzigd door Alarmnummer op 04-11-2005 06:55 ]

[Robtimus]

eghie schreef op donderdag 03 november 2005 @ 21:52:

offtopic:
Wat vind je irritant aan het hoofdletter gebruik? Dan zal ik wat proberen te minderen

offtopic:
In Java is het standaard om variabelen en methods met een kleine letter te laten beginnen, en verder elk volgend woord in de naam met een hoofdletter. Bv getSomeValueOrSomethingLikeThat(), someInterestingVariable. Jij schreef je variabelen met een hoofdletter op het begin, questa deed dat met methods.
In andere talen zoals VB is jullie stijl dan weer wel gewenst, maar in Java is dat not-done; bij certificering kun je het vrijwel shaken als je niet de Java standaard stijl gebruikt (hard, zelfs triest misschien, maar waar).

[JKVA]

Hoewel ik het helemaal met Alarmnummer eens ben wat betreft ontwerp, zou je eventueel met het gebruik van final volgens mij vooruit kunnen. Tenminste ik begrijp dat je die variabelen een keer wil zetten en dan alleen opvragen. Bijvoorbeeld zo:

Java:

class Klasse
{
    public final int portNr;

    ...

    public Klasse(int portNr)
    {
        this.portNr = portNr;
    }
}

// Ergens anders
Klasse a = new Klasse(1234);

De enige plaats om de final variabele te zetten is in de constructor.

Overigens is dit lelijk programmeren en kun je het best voor de oplossing van AlarmNummer gaan, maar met final is het mogelijk

Overigens is het naar mijn idee minder foutgevoelig en netter om een singleton als een abstracte klasse met statics te maken dan een interface die een object teruggeeft waar je de clone van moet overschrijven om zeker te zijn dat je maar één instantie hebt.

[Confusion]

eghie schreef op donderdag 03 november 2005 @ 16:20:
Allemaal heel leuk en aardig, maar als ik dit zo doe kun je in de hele applicatie ook die waarden veranderen, ik wil dat echter niet toestaan.

Waarom wil je dat het expliciet onmogelijk is? Als er een publieke methode bestaat om de settings te veranderen, en dat zal wel moeten als je ze wilt kunnen inputten, dan kan iemand met code toegang altijd zorgen dat andere klassen die methode ook kun gebruiken. Je kan het iemand met code toegang niet onmogelijk maken stomme dingen te doen. Je kan het ontwerp alleen zo opzetten dat het het doen van stomme dingen ontmoedigt. Iets moeilijk maken is als security through obscurity: het werkt uiteindelijk niet.

[ Voor 10% gewijzigd door Confusion op 04-11-2005 09:17 ]

[pjvandesande]

JKVA schreef op donderdag 03 november 2005 @ 23:50:
De enige plaats om de final variabele te zetten is in de constructor.

Ik vind een getter iets netter (wat een rijm wonder die questa ). Zo kun je namelijk altijd nog een setter er bij gooien met een anderen scope.

Je kun met een goede refactor tool natuurlijk een hoop oplossen, maar als je er later voor kiest om class.Object om te zetten naar class.GetObject moet je dat door je hele code veranderen.
Handig is anders.

[Verwijderd]

IceManX schreef op donderdag 03 november 2005 @ 22:55:

offtopic:
In Java is het standaard om variabelen en methods met een kleine letter te laten beginnen, en verder elk volgend woord in de naam met een hoofdletter. Bv getSomeValueOrSomethingLikeThat(), someInterestingVariable.

offtopic:
private String eMailAddress;
public String geteMailAddress(){...}

[eghie]

Alarmnummer schreef op donderdag 03 november 2005 @ 21:59:
Ik zou een beetje oppassen met het gebruik van singletons. Als een object bepaalde dependencies heeft, dan injecteer ik het gewoon in dat object en laat ik object niet zoeken naar de singleton waar de informatie in staat. Het voordeel is dat je oa veel beter testbare code krijgt, maar ook dat je veel herbruikbare code krijgt omdat je tot in de kleinste details kunt controleren wat erin gaat.

Ik ben zelf tot deze ontdekking gekomen sinds ik Spring gebruik, maar heb intussen ook ingezien dat mijn manier van werken totaal is veranderd, zonder het gebruik van Spring. Wat ik zou doen is eerst proberen te functionaliteiten proberen te scheiden. Jouw ServerProperies hebben 2 functionaliteiten:
1) laden van properties
2) opslagcontainer voor properties.
Op het moment dat jij je properties ergens anders vandaan wilt laten komen (bv een database), of als je dezelfde class wilt gebruiken voor verschillende instanties, dan kom je zwaar in de problemen.

Daarom probeer ik functionaliteiten van classes dus te scheiden.

In pseudecode zou ik het als volgt aanpakken:
ServerConfig serverConfig = ServerConfigPropertiesFileLoader.load(''some.file");
Server server = new Server(serverConfig);

Op deze manier kan je bv ServerConfig hergebruiken zonder dat je vast zit aan het properties bestand. Je zou bv ook kunnen zeggen:

ServerConfig serverConfig = ServerConfigDatabaseLoader.loadRecord(1);
Server server = new Server(serverConfig);

En dan de singletons. Met de singletons heb je gewoon een groot probleem dat je niet onder die instantie uit komt. Singletons zijn denk ik wel het meest gebruikte design pattern en in 99% van de gevallen zorgen ze voor grote problemen binnen een ontwerp.

Stel dat ik jouw service op 2 poorten zou willen aanbieden? Hoe zou ik dat moeten doen?? Dat gaat dus niet lukken met een Singleton. Wel als je het geen singleton maakt.

vb:

ServerConfig serverConfig1 = ServerConfigPropertiesFileLoader.load(''some.file");
Server server1 = new Server(serverConfig1);
ServerConfig serverConfig2 = ServerConfigPropertiesFileLoader.load(''someother.file");
Server server2 = new Server(serverConfig2);

Op deze manier krijg je niet van die stijve ontwerpen. In 99% van de gevallen zijn Singletons bad bad bad.

Hmm, nu je het over meerdere server instanties hebt, heb je wel gelijk eigenlijk. Dit is dan wel een betere methode. Ik ging zelf eigenlijk eerst uit van dat er toch maar 1 instantie van de server wordt gebruikt, vandaar ook die singleton. Ik zou me namelijk niet kunnen voorstellen dat iemand meer instanties wou gaan kunnen gebruiken voor de server, maar nu je het zo zegt kan ik het me wel voorstellen. Het is wel beter om de priviledges te scheiden. Of bijvoorbeeld voor elke aparte VLAN/LAN een andere server. Dan kan ik inderdaad beter deze methode gebruiken.

En ander belangrijk concept is dat je moet werken met layers/rings. In jouw geval heb je bepaalde core functionaliteit dat toegepast kan worden in een lokale maar ook in een remote omgeving. Het remote gedeelte zit als een ring om het lokale gedeelte heen. Stel dat je een bepaalde (lokale) dienst heb die je remote wilt maken (weer via die 2 poorten).

LocalService localService = new LocalService(....);
ServerConfig serverConfig1 = ServerConfigPropertiesFileLoader.load(''some.file");
RemoteServer server1 = new RMIRemoteServer(serverConfig1,localService);
ServerConfig serverConfig2 = ServerConfigPropertiesFileLoader.load(''someother.file");
RemoteServer server2 = new RMIRemoteServer(serverConfig2,localService);

Op deze manier kan je de localService delen tussen 2 verschillende remote service interfaces. Het voordeel hiervan is dat hele hele remoting aspect niet zo`n gruwelijke invloed krijgt op je design. Je kan bv dezelfde LocalService delen met een webinterface, met een RMI service en met een Hessian Service. Het is ineens geen onderdeel meer van je architectuur, maar een implementatie detail.

Dit concept snap ik niet helemaal. Zou je mischien kunnen uitleggen, mischien aan de hand van een voorbeeld, wat je precies bedoelt met die lokale en remote omgevingen? Dat van die lagen snap ik ongeveer wel wat je ermee bedoeld. Dat is opzich wel een goed idee. Hier moet ik me nog wel iets in verdiepen in ieder geval.

Ben ook al bezig met wat "secure programming guides voor java" te lezen, om te kijken van wat ik het best kan vermijden. daar heb ik ook al geleerd om bijvoorbeeld cloning uit te zetten, classen die niet geserialized hoeven te worden zowel serializen als deserializen blokkeren. Dus ben me eerst ff goed aan het voorbereiden voordat het echte code werk gaat beginnen.

IceManX schreef op donderdag 03 november 2005 @ 22:55:
[...]

offtopic:
In Java is het standaard om variabelen en methods met een kleine letter te laten beginnen, en verder elk volgend woord in de naam met een hoofdletter. Bv getSomeValueOrSomethingLikeThat(), someInterestingVariable. Jij schreef je variabelen met een hoofdletter op het begin, questa deed dat met methods.
In andere talen zoals VB is jullie stijl dan weer wel gewenst, maar in Java is dat not-done; bij certificering kun je het vrijwel shaken als je niet de Java standaard stijl gebruikt (hard, zelfs triest misschien, maar waar).

Ik zal erop letten. Bedankt in ieder geval dat je me erop gewezen hebt.

JKVA schreef op donderdag 03 november 2005 @ 23:50:
Hoewel ik het helemaal met Alarmnummer eens ben wat betreft ontwerp, zou je eventueel met het gebruik van final volgens mij vooruit kunnen. Tenminste ik begrijp dat je die variabelen een keer wil zetten en dan alleen opvragen. Bijvoorbeeld zo:

Java:

class Klasse
{
    public final int portNr;

    ...

    public Klasse(int portNr)
    {
        this.portNr = portNr;
    }
}

// Ergens anders
Klasse a = new Klasse(1234);

De enige plaats om de final variabele te zetten is in de constructor.

Overigens is dit lelijk programmeren en kun je het best voor de oplossing van AlarmNummer gaan, maar met final is het mogelijk

Overigens is het naar mijn idee minder foutgevoelig en netter om een singleton als een abstracte klasse met statics te maken dan een interface die een object teruggeeft waar je de clone van moet overschrijven om zeker te zijn dat je maar één instantie hebt.

Sinds ik heb uitgevogeld dat final variablen ook geset kunnen worden binnen de constructor leek mij dat een goede oplossing. final variablen zijn namelijk readonly nadat je het de 1e keer geset hebt. Dit wou ik ook aangezien ik het verder in m'n app niet wil veranderen, want het zijn instellingen. Nu kun je er ook een private variable van maken en dan alleen een get functie erop knallen, geeft eigenlijk hetzelfde principe. Maar die final scheelt me wat aan code, gezien ik niet voor elke variable nog eens een get functie moet gaan gebruiken. Maar met zo'n get functie kun je wel wat controlles ertussen gooien voordat je je variable wilt terug geven. Natuurlijk controlleer ik de variablen ook al als ze worden geset. Nu zit ik eigenlijk een beetje te dubben welke methode ik zou nemen. Ik denk eigenlijk dat laatste, want als er toevallig nog wat controlles moeten gebeuren, dan kan het er makkelijker bijgezet worden, zonder dat het al te veel invloed heeft op de rest van de code. En wat questa zegt is natuurlijk ook waar, je kunt makkelijker veranderingen doorvoeren in je code zonder dat het van invloed is op de rest van de code.

Confusion schreef op vrijdag 04 november 2005 @ 09:16:
[...]

Waarom wil je dat het expliciet onmogelijk is? Als er een publieke methode bestaat om de settings te veranderen, en dat zal wel moeten als je ze wilt kunnen inputten, dan kan iemand met code toegang altijd zorgen dat andere klassen die methode ook kun gebruiken. Je kan het iemand met code toegang niet onmogelijk maken stomme dingen te doen. Je kan het ontwerp alleen zo opzetten dat het het doen van stomme dingen ontmoedigt. Iets moeilijk maken is als security through obscurity: het werkt uiteindelijk niet.

Dit is uiteindelijk ook de bedoeling. Stomme dingen ontmoedigen, maar ook beveiligings redenen. Ooit komt er gebruikersinput aan te pas in de applicatie, nu moet ik hier wel op filteren. Maar stel je vergeet de input te filteren op een paar zaken, waar je geen rekening mee gehouden hebt, dan wil ik wel dat je niet teveel de applicatie kunt wijzigen in z'n werkwijze. Dus probeer ik de applicatie op alle lagen wel te beveiligen. Ook gaat er een module ondersteuning inkomen, nu wil ik zoveel mogelijk fouten daarin afdwingen, gezien ik niet alle modules zelf ga maken. En je moet niet op security through obscurity vertrouwen, maar je kunt het wel naast je huidige beveiliging gebruiken, om het allemaal nog moeilijker te maken. Je kunt er altijd wel wat mee afweren.

[Alarmnummer]

eghie schreef op zaterdag 05 november 2005 @ 11:24:
[...]
Hmm, nu je het over meerdere server instanties hebt, heb je wel gelijk eigenlijk. Dit is dan wel een betere methode. Ik ging zelf eigenlijk eerst uit van dat er toch maar 1 instantie van de server wordt gebruikt, vandaar ook die singleton. Ik zou me namelijk niet kunnen voorstellen dat iemand meer instanties wou gaan kunnen gebruiken voor de server, maar nu je het zo zegt kan ik het me wel voorstellen. Het is wel beter om de priviledges te scheiden. Of bijvoorbeeld voor elke aparte VLAN/LAN een andere server. Dan kan ik inderdaad beter deze methode gebruiken.

Het is niet alleen handig om meerdere instanties aan te kunnen maken. Het komt de reuse ook tengoede (omdat objecten minder verantwoordelijkheden hebben kan je ze eenvoudiger in andere contexten gebruiken) en het komt de testbaarheid ook tengoede omdat je eenvoudiger met de hand er data in kunt zetten.

Deze manier van werken heet trouwens dependency injection. Zorg dat je het idee hierachter onder de knie krijgt en dan gaat er een wereld voor je open.

Dit concept snap ik niet helemaal. Zou je mischien kunnen uitleggen, mischien aan de hand van een voorbeeld, wat je precies bedoelt met die lokale en remote omgevingen?

Ik zet het meestal als volgt op. Ik zet een lokale service (dus een normaal object dat niet gebruikt gaat worden in een netwerk omgeving) op. Als ik nu deze dienst wil aanbieden als een remote service, maak ik een soortement van gateway waardoor de lokale dienst te gebruiken valt. Deze gateway zorgt voor de uitwisseling van data met de client (hiervoor kan je bv gebruik maken van Data Transfer Objects: DTO). En verder kun je aan de gateway nog allerlei andere dingen toevoegen, bv security.

Het voordeel is dat jij jouw lokale dienst kunt hergebruken. Stel dat jij ineens een Webservice interface wilt aanbieden? Of dat je ineens via een socket die lokale dienst moet gebruiken? Op het moment dat jij die Lokale dienst niet afhankelijk maakt van de middleware krijg je gewoon veel beter herbruikbare componenten.

Als ik bv naar Spring kijk, dan kan je remoting over het algemeen reduceren tot een configuratie issue.

Ben ook al bezig met wat "secure programming guides voor java" te lezen, om te kijken van wat ik het best kan vermijden. daar heb ik ook al geleerd om bijvoorbeeld cloning uit te zetten, classen die niet geserialized hoeven te worden zowel serializen als deserializen blokkeren.

Je DTO`s zijn je data uitwisselings objecten. Een client mag daar mee doen wat die wil, maar het is onmogelijk dat de client bij interne structuren van jou kan komen. Op het moment dat jij een DTO terug krijg, pak jij veld voor veld die informatie er weer uit. De client kan jouw dus niet beduvelen omdat je hem nooit jouw interne objecten hebt gegeven.

Een ander nadeel aan interne objecten aan een client geven, is dat je de client toegang verleend tot de darmen van je systeem. De client en de server die zijn nu aan elkaar gekoppeld en wijzigingen maken gaat nu veel lastiger. Met DTO`s icm een remote service zorg je ervoor dat je een duidelijk communicatie contract hebt met de buitenwereld, maar niemand hoeft te weten hoe de binnenkant eruit ziet.

[eghie]

Alarmnummer schreef op zaterdag 05 november 2005 @ 12:01:
[...]

Het is niet alleen handig om meerdere instanties aan te kunnen maken. Het komt de reuse ook tengoede (omdat objecten minder verantwoordelijkheden hebben kan je ze eenvoudiger in andere contexten gebruiken) en het komt de testbaarheid ook tengoede omdat je eenvoudiger met de hand er data in kunt zetten.

Deze manier van werken heet trouwens dependency injection. Zorg dat je het idee hierachter onder de knie krijgt en dan gaat er een wereld voor je open.

Bedankt, er gaat inderdaad een wereld voor me open. Ook leuk om plug-ins mee te maken. Ik ben er nu een artikeltje over aan het lezen (Inversion of Control Containers and the Dependency Injection pattern), maar ik moet zeggen, het ziet er al veelbelovend uit. Dit zijn leuke weetjes moet ik zeggen.

Ik zet het meestal als volgt op. Ik zet een lokale service (dus een normaal object dat niet gebruikt gaat worden in een netwerk omgeving) op. Als ik nu deze dienst wil aanbieden als een remote service, maak ik een soortement van gateway waardoor de lokale dienst te gebruiken valt. Deze gateway zorgt voor de uitwisseling van data met de client (hiervoor kan je bv gebruik maken van Data Transfer Objects: DTO). En verder kun je aan de gateway nog allerlei andere dingen toevoegen, bv security.

Het voordeel is dat jij jouw lokale dienst kunt hergebruken. Stel dat jij ineens een Webservice interface wilt aanbieden? Of dat je ineens via een socket die lokale dienst moet gebruiken? Op het moment dat jij die Lokale dienst niet afhankelijk maakt van de middleware krijg je gewoon veel beter herbruikbare componenten.

Als ik bv naar Spring kijk, dan kan je remoting over het algemeen reduceren tot een configuratie issue.

[...]

Je DTO`s zijn je data uitwisselings objecten. Een client mag daar mee doen wat die wil, maar het is onmogelijk dat de client bij interne structuren van jou kan komen. Op het moment dat jij een DTO terug krijg, pak jij veld voor veld die informatie er weer uit. De client kan jouw dus niet beduvelen omdat je hem nooit jouw interne objecten hebt gegeven.

Een ander nadeel aan interne objecten aan een client geven, is dat je de client toegang verleend tot de darmen van je systeem. De client en de server die zijn nu aan elkaar gekoppeld en wijzigingen maken gaat nu veel lastiger. Met DTO`s icm een remote service zorg je ervoor dat je een duidelijk communicatie contract hebt met de buitenwereld, maar niemand hoeft te weten hoe de binnenkant eruit ziet.

Dus een soort van framework die ertussen hangt. Dat qua code vorm ongeveer gelijk is aan een Business Object layer in het N-Tier model. Dus de "client" (om het maar even zo te noemen), is zich niet bewust van wat onder de motorkap zit. Hmm, dat remote service gebeuren ook maar eens uitzoeken.

Ik moet zeggen, dit geeft wel leuke perspectieven over het designen van software. Ook wel mooi is dat JAVA en ook mijn Eclipse editor er een beetje naar neigen om je software goed te designen.