Modulare Programmierung, SchnittstellenDesign .. passende Literatur ?

[RHBaum]

Hallo Leuts,

<Einleitung>

Ich hab hier (auf Arbeit) nen momentan riesiges Problem.

Wir haben hier ein grösseres project, was aus mehreren "Modulen" besteht.
ganz frueher waren die Schnittstellen mal COM, nachdem man aber den COM-Mechanismus seinen Anforderungen unterwerfen wollte (Man hat sogar einige COM funktionen umgeschrieben, und ne eigene registrierung der COM-Module ohne regestry versucht zu entwickeln ) ist man aber schnell in ne Sackgasse gekommen.

Nun bauen wir mehr C++ Interfaces ... soweit so gut, das ist aber auch mein Problem.

Wir verwenden Qt, und MS COmpiler.
Die Schnittstellen trotzen vor QT abhaengigkeiten.
Die Kroenung sind Schnittstellen ala:

class MyInterface : public Irgendeine_QOBJECT_abgeleite_klasse 
{
    Q_OBJECT
public:
    /// CTOR, DTOR 
    /// wenigstens ist der DTOR virtuell 

    virtual QVector<QIrgendwas> myMethod(const QVector<int> & param) = 0;
};

Abhaengigkeitstechnisch ist das nu der Horror.
Und solche Schnittstellen gehen bei uns ueber Dlls ...
Die oder der Programmierer macht extensiven gebrauch von Signal / Slot Mechanismuss (deswegen auch die QObject Ableitung in allen Schnittstellen), auch ueber DLL grenzen hinweg.

Das Problem ist,das es absolute rudimentäre Schnittstellen auch betrifft, wie unseren Pluginmechanismus etc ... Also fast jedes Modul muss sowas implementieren.

Man hat jahrelang ned auf mich und andere gehört ...

Wie immer argumentiert wurde:
- C-Schnittstellen sind unmodern , wir sind im 20-Jahrhundert !
- QT ist doch mittlerweile Standard ...
- Wir schreiben unseren Entwicklern vor, was verwendet werden muss, also COmpiler und QT-version. Binaerabhaengigkeiten sind doch damit kein problem fuer uns !

Nun kommen so langsam die Nachteile zum tragen:
- Einige unsere Module sollen in anderen Projeckten auch verwendet werden, die koennen keine QT verwenden (Lizenzfrage !) bzw haben andere Versionen. Auch compilerversionen (VS studio 2008, statt wie wir 2005).
- wir wollen auf 2010 umstellen, da muessen einige andere Module von Fremdanbietern(die haben diese Module nach unseren kranken Specs erstellt) angepasst werden. Nun wundert sich unsere Projectleitung, warum die Firmen (mit einer haben wir aus anderen Gruenden die Zusammenarbeit eingestellt) ploetzlich weniger Kooperativ sind, bzw meinen ... klar kein problem, nur 5000 EUR, und wir machen das ^^ (entruesteter Projectleiter: die muessen doch nur neukompilieren ??? was soll der Sch... )
- Wir wollen einen Buildwerver aufsetzen ... Durch die unterschiedlichen Abhaengigkeiten, also QT versionen, Visual Studio versionen und von uns noch einigen Build-Varianten komm ich auf eine maximal Mögliche Anzahl von Kombination von 4 (uns bekannte Qt versionen im EInsatz) * 3 (uns bekannte Visual Studio Versionen im Einsatz) * 4(unserer Varianten) * 2 (Release Debug Build) = 96 Tragets !!! pro (von usn nach aussen gegebenen ) Modul und Version ! Dazu braeucht ich ne Serverfarm !

Hauptproblem ist, das weder ProjectManager so richtig, aber erst recht nicht die involvierten programmierer Ihre Interfaces als Problem ansehen.
Wenn ich damit ankomme, heisst:
- ich waer nen "Software-Esotheriker" ...
- die verfügbaren Tools passen fuer uns einfach ned (Weil wir die Varianten ned gemanged bekommen) ...
- die QT machts doch auch so, und da funktionierts (Templates in Schnittstelle)

- X kennt Y in ner anderen Firma, und die machen auch sowas ... bei denen ist das gar kein Problem (ob die software unur ansatzweise ähnliche Anforderungen hat, weiss keiner, und kriegt man auch keine Antwort ... )

Sie sehen einfach keinen Zusammenhang zwischen Ihren Design, und Problemen die andere (andere Abteilungen, der arme der die Builds verwalten muss ... etc) damit haben.

</Einleitung>

Also ich kann technisch argumentieren wie ich will, ich red wie gegen Wände.
Und was halt taktisch immer priorisiert gewinnt, ist das Kostenargument. Ne Umstellung waer zu teuer ... etc.
Mir waer schon recht wenn neue Schnittstellen wenigstens "gescheit" gemacht wuerden ...

Fazit, ich brauch Irgendwas, was glaubwuerdiger ist wie ich, und sich mit dem Thema auseinandersetzt.
Fach-Literatur waer super, allerdings muss sie verstaendlich sein (Paar passagen aus exceptional C++ usw hab ich mal versucht anzubringen, aber das Buch waer veraltet und nur fuer Hacker)
Auch noch nen Highlight:
F: "Was glaubts warum Xerces-C, libsvn, openssl, noch ne C-Schnittstelle hat, wo das doch so unmodern ist ?"
A: "die koennens halt nicht besser! Sollen sich mal nen Beispiel an (ehemals) trolltech nehmen".

Vielleicht koennts Ihr mir ja bissi helfen.

Ciao ...

[nn]

Hallo,

ich glaube ihr habt da in der Tat ein Riesenproblem. Ob sich dabei jemand von einem Buch überzeugen lassen wird, sei mal dahingestellt ...

Ein Buch was zumindest zeigt, welche Optionen es gibt, wäre z.B. dieses

http://www.apibook.com/blog/

[Artchi]

Sollte da nicht jedes Patternbuch herhalten? Z.B. das "Patterns Kompakt" aus dem Springer-Verlag. Finde ich super das Buch. Der Name ist Programm: die Patterns werden sehr gut beschrieben, mit relevanten Praxisbezug. Da kann man ja mal ein paar Patterns raus greifen.

Dann sollte auch "Effektiv C++ Programmieren" ein Argument sein: zwei drei Tips über Pimpl, Adapter usw. Im Prinzip "Patterns Kompakt" speziell für C++.

Sein wir doch mal ehrlich: wer die Patterns von GoF kennt, stellt sich nicht stur.

Aber ich muß dich schon fragen, was an C-Schnittstellen besser sein soll, als an C++-Schnittstellen? Ich kann auch mit C++ weniger Abhängigkeiten haben.

Das man jetzt ein bestehendes System nicht über den Haufen werfen kann, ist klar. Du wirst in jeder Firma/Projekt auf Widerstand stossen, wenn du produktiven Code verbannen willst.

Die bessere Strategie ist es, den bestehenden Code als Implementierung weiter zu verwenden, und ihn hinter Adaptern, Wrappern oder Proxies zu verstecken! Und darauf zu setzen, das neue Projekte diese entsprechend nutzen. Da ist es viel einfacher, weil man eh in ein neues Projekt investieren muß.

Legacy-Projekte werden dagegen den alten Code weiter direkt nutzen müssen/können, und evtl. später (wenn der Support mal nichts weiter zu tun hat... Ha Ha!) auf die neuen Schnittstellen migriert.

Mit diesem Vorgehen wirst du eher auf Zustimmung stossen, als mit der Brechstange.

[nn]

Artchi schrieb:

Z.B. das "Patterns Kompakt" aus dem Springer-Verlag. Finde ich super das Buch.

Ja, ich auch. Aber das von mir verlinkte, ist mehr als ein Pattern-Buch.

Artchi schrieb:

Aber ich muß dich schon fragen, was an C-Schnittstellen besser sein soll, als an C++-Schnittstellen? Ich kann auch mit C++ weniger Abhängigkeiten haben.

Zumindest hat man in C weniger Probleme mit Binärkompatibilität. Wenn externe Firmen irgendwelche Plugins schreiben wollen/sollen, wollen sie das selten mit der Compilerversion des konkreten Projektes. Oder sie wollen mit Delphi, Matlab oder was weiß ich, auf Schnittstellen zugreifen. Das zeigt einfach die Praxis.

Die zeigt aber auch, dass C-Schnittstellen für komplexe objektorientierte Software meist keine so glückliche Wahl sind.

[Artchi]

Soweit mir bekannt, kann man bei DLLs, COM und ActiveX Compiler-unabhängig C++-Schnittstellen anbieten. Man darf nur nicht den Client-Code z.B. die Objekte verwalten lassen. Sprich man muß Factory-Methoden anbieten, so wie man es von COM-Objekten kennt.

Jedenfalls würde ich deshalb nicht auf C++ verzichten, wenn ich das durch Einhaltung einer bestimmten Regel schaffen kann.

[nn]

Artchi schrieb:

Soweit mir bekannt, kann man bei DLLs, COM und ActiveX Compiler-unabhängig C++-Schnittstellen anbieten.

Kannst du das für die DLLs im allgemeinen mal bitte erklären ?

Wie sieht eine compilerunabhängige C++ DLL-Schnittstelle aus, die Objekttypen oder gar Templates verwendet ?

COM exportiert ja keine Objekte im C++ Sinne, sondern nur Tabellen von Funktionszeigern. Die Basisdatentypen sind im Prinzip das was in VARIANT enthalten ist, mit BSTR gibt es einen eigenen Stringtyp, usw.

[RHBaum]

Soweit mir bekannt, kann man bei DLLs, COM und ActiveX Compiler-unabhängig C++-Schnittstellen anbieten

So kenn ich es auch!
Aber sind COM Interfaces nicht auch C-Konstrukte (structs + funktionspointer)?
Glaub hab sogar mal nen buch gesehen, wo man COM mit nem c-compiler programmiert hat.
Aber definitiv kann man z.b. mit dem mingw DirectX (COM) befeuern, und ich vermut das die directX implementation sicher nicht mit einem mingw c++ binärkompatiblen compiler übersetzt wurde oder ?

Und ja fuer unseren Fall waer es definitiv nur eine Schnittstelle die an externe Hersteller geht ...
Für das gesamte Project ist sicher ein arbeiten mit c-Schnittstellen keine alternative.

Weiterhin gehts auch darum, das die Entwickler sich nen Kopf machen sollen, welche Schnittstellen Projektintern, also sowieso an das Binary gebunden sind.
Da z.b. seh ich Qt Abhanegigkeiten nicht ganz so drastisch ...

Aber wenns ums design einer Schnittstelle geht, die externe Module verwenden sollen, da wirds langsam tödlich ...

Das man jetzt ein bestehendes System nicht über den Haufen werfen kann, ist klar. Du wirst in jeder Firma/Projekt auf Widerstand stossen, wenn du produktiven Code verbannen willst.

Ja wenn der code einwandfrei funktionieren wuerde ....
Ein riesenproblem was wir weiterhin haben, sind Memory leaks ... und "unsauberes Beenden"

(ich vermute new und delete an Qt klassen in unterschiedlichen Dlls aufgerufen, und durch untzerschiede in der Implementation kommts vielleicht dazu .. iss aber nur ne vermutung )

Aber ein Hauptproblem in dem Zusammenhang ist, das ich nicht gescheit "debuggen" kann, weil ... durch die Macros und inline funktionen etc debug und release die schnittstellen nicht binaerkompatibel sind. (ESD fehler bei ausfuehren, wenn irgendwo release und debug vermischt werden).
Und ich hab manchmal probleme die debug versionen zu übersetzen ...

Weiterhin wird bei uns der M$ Memory Leak detektor prinzipiell abgeschalten, weil: die QT angeblich offiziell ein Problem mit hat.
(ich teste auch mit ner qt anwendung meine Impls, da hab ich das problem nicht).

Wie gesagt, ich hab kein problem wenn wer intern die QT verwendet. Ich mach z.b. auch extensiv gebrauch von boost:filesystem, aber das weiss natuerlich keiner, weils in meinen schnittstellen nicht auftaucht ...

Jedenfalls würde ich deshalb nicht auf C++ verzichten

Ich verwend groesstenteils auch C++ Klassen, aber 100% Abstract.
(nur der virteulle DTOR hat ne leere Implementation)
Und fahr eigentlich ganz gut damit ... nur wenn ich die anderen Schnittstellen bedienen muss, fangen die Probleme an ...

wenn ich das durch Einhaltung einer bestimmten Regel schaffen kann.

Hier bin ich eben nicht so firm ....

Ich versuch meisten nen create / release - Muster umzusetzen ...

Also sowas:

class IMyClass 
{
public:
    const ISubClass * createSubClass( Prams params) const = 0;
    void releaseSubClass(const ISubClass * pSub) const = 0;
protected:
    virtual ~ISubClass(){} 
};

Sowas versteht jeder, und das sollt so sicher wie möglich sein.
Und ich brauch ned unmengen an Prosa und regeln dazu schreiben ...

Aber mir fehlt da auch bisserl der Background ... (Bin kein studierter Informatiker, das ist quasi ausm bauch raus ...)

Bei der Factory Methode gehen hier schon wieder die Disskussionen los.
Darf ich eine Klasse, die in einer anderen Übersetzungseinheit erzeugt wurde, in meiner Übersetzungseinheit gefahrlos löschen ?

Ich wuerd sagen, kommt auf die Abhaengigkeiten an ... sind die klassen 100% gleich definiert, sollt ich kein Problem haben .. was aber wenn nicht ???
Wenn in unterschiedlichen Einheiten unterschidliche Compilereinstellungen sind ? Alignment und sowas ?

Dazu waer eben Literatur ned schlecht ....

Ciao ...

[Zeus]

RHBaum schrieb:

Aber mir fehlt da auch bisserl der Background ... (Bin kein studierter Informatiker)

Sowas lernen sie sowieso nicht. Also (k?)ein Nachteil für dich.

http://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL

[knivil]

Informatiker lernen aber sowas wie Model-View-Controller. Das als Schlagwort.

Dazu waer eben Literatur ned schlecht ....

Darueber werden keine Buecher geschrieben, denn sobald das Manuskript fertig ist, ist das Wissen veraltet. Foren, Blogs oder Newsgroups sind die bessere Anlaufstellen.

Auch scheint euerer Problem nicht Literatur zu sein, sondern fehlende Richtlinien.

[Zeus]

knivil schrieb:

Informatiker lernen aber sowas wie Model-View-Controller. Das als Schlagwort.

Ein studierte Informatik würde niemals solche Probleme vorfinden wie bei RHBaum?

[Artchi]

RHBaum! Der Ansatz ist ja schon mal richtig. COM-Objekte lässt man erzeugen, d.h. der Client-Code besorgt sich das Objekt nur. Und für die Freigabe ist auch nicht der Client-Code zuständig! Deshalb zählen die COM-Objekte ihre Referenzen selbst. Das kann man in "Modernes C++ Design" im Kapitel über Smartpointer nachlesen. Der Intrusiv-Smartpointer aus Boost (und C++11?) ist sogar für solche Fälle gedacht! Schau dir mal die Doku zu intrusive_ptr an.

So löst man auch das Thema "unterschiedliche C++-Runtime-Version", in dem man die DLL "mal machen lässt".

Zeus! Sehr guter Artikel! Danke!

nn! Die COMs sind C++, aber da am Ende eh alles nur nach Maschinencode kompiliert, kannst du natürlich auch COM über C ansprechen, genauso wie es auch über Delphi und vielen anderen Sprachen geht. Aber wer will freiwillig COM-Objekte mit C nutzen, wenn er es mit C++ kann?

Strings werden natürlich nur Roh im Interface genutzt. Stimmt. Weil std::basic_string halt keine binäre Klasse ist sondern nur ein Template. Liegt in der Natur der Sachde. Ändert aber nichts daran, das ich vom Host-Code (DLL) ein binären String-Objekt-Typ nutzen könnte, also sowas wie IMyString mit echten Methoden.

Es ist aber einfacher zu sagen: der Host-Code gibt mir den rohen String, und ich pack gleich eine Kopie in mein String-Objekt. Strings sehe ich als PODs an.

[RHBaum]

Auch scheint euerer Problem nicht Literatur zu sein, sondern fehlende Richtlinien.

Nein, das geht tiefer !
Setz mal 5 Programmierer an einen Tisch, und lass sie über Regeln disskutieren.
Wir sind keine IT Abteilung ... das merkt man grad hier deutlich.
Uns fehlen die ressourcen und vor allem Leute (oder ein Projektleiter) die fundiert sagen koennten, "so ists richtig und so nicht" !

Ciao ...

[nn]

Artchi schrieb:

Aber wer will freiwillig COM-Objekte mit C nutzen, wenn er es mit C++ kann?

Niemand. Das habe ich auch nicht gesagt.

Wo ich dir entschieden widerspreche ist die Behauptung

Artchi schrieb:

Die COMs sind C++

Das ist falsch.

COM-Interfaces lassen sich durch Methoden von C++ Klassen darstellen. Das ist der Weg, wie COM in C++ abgebildet wird. Aber nicht alle C++ Konstrukte lassen sich 1:1 in COM abbilden.

Visual Basic 6 "Objekte" waren COM Objekte, das war eine 1:1 Abbildung. Deswegen schreibe ich noch lange nicht COM wäre Visual Basic.

Die Aussage

Artchi schrieb:

Soweit mir bekannt, kann man bei DLLs, COM und ActiveX Compiler-unabhängig C++-Schnittstellen anbieten.

stimmt nur für COM und ActiveX (und für C und C++/CLI), für C++ ist sie falsch.

Die ABIs der Windows C++ Compiler der einzelnen Hersteller (und mancher ihrer Compilerversionen) unterscheiden sich. Wie ein Compiler das Layout einer Klasse im Speicher anrichtet ist nicht genormt.

Das ist bei COM anders. Dort werden nur Interfaces und die Basistypen exportiert. Alle Datentypen außer den Grundtypen werden wieder als Interfaces realisiert und i.a. durch Factories erzeugt. Ich zitier mal Wikipedia

Eine Schnittstelle erfüllt die Funktion einer abstrakten Klasse, die lediglich virtuelle Elementfunktionen enthält, die (wegen der Trennung von Deklaration und Implementierung) in der VTable alle auf 0 gesetzt werden. Die C-Version einer Schnittstelle ist entsprechend eine Struktur, die Funktionszeiger enthält. Die erzeugten COM-Objekte nutzt man dabei über Zeiger auf deren Schnittstellen.

Wenn ein COM-Objekt eine Schnittstelle implementiert, muss es alle Methoden der Schnittstelle überschreiben, also die VTable füllen. Dabei sind mindestens die drei Methoden von IUnknown zu implementieren, die für das Lebenszyklusmanagement zuständig sind und eventuell vorhandene, weitere implementierte Schnittstellen offenlegen.

C++/CLI und das C++/CX für die nächste COM-Version umgehen die Problematik durch Metadaten. Da kann man auch Klassen mit Datenmembern exportieren.

Wenn man die Behauptung "C++ aus DLL exportiert ist COM" ernstnimmt, wäre ja auch exportiertes Qt, wie im obigen Beispiel, COM. Was ja offenkundig nicht der Fall ist. Könnte man exportierte C++ Klassen aus DLLs in anderen Compilerversionen ohne Probleme verwenden, hätte der Threadersteller ja wohl keine Mühe mit dem Wechsel von VS 2005 auf 2008 oder 2010.

Und um es noch mal zu sagen:

Ich bevorzuge für unsere eigenen Module C++ Schnittstellen in den DLLs. Aber ohne Verweise auf externe Libs wie Qt in den Schnittstellen.

Da das nur mit einer Compilerversion funktioniert, gibt es für einige wenige externe Schnittstellen kleine schlanke C-Interfaces. Die haben sich als robuster und portabler erwiesen als COM.

Für unsere und externe Schnittstellen zu C# verwenden wir heute C++/CLI statt C-Exporte und PInvoke. Wer mag, kann die .net Interfaces dann auch gerne über COM benutzen.

Ach ja, was ist an dem Buch, was ich empfohlen habe, so schlecht, dass es hier ignoriert wird ? Es behandelt ziemlich genau diese Thematik, auch im Kontext von Patterns.

[Chew-Z]

"...und ne eigene registrierung der COM-Module ohne regestry versucht zu entwickeln..."
COM geht auch ohne Registry, indem man Manifeste verwendet.

[Chew-Z]

COM ist in Windows derart tief verwurzelt, das ich mir auf Anhieb nicht so recht vorstellen kann was man damit nicht erschlagen kann sofern das notwendige Know-How vorhanden ist. Nein es ist keine 1:1 Umsetzung von C++, man muß Probleme gelegentlich schon etwas anders durchdenken und lösen als in C++. Aber unter Windows ist es meines Erachtens immer noch der binärkompatible Objektstandard, wenn man kein .NET verwenden will/kann. Wobei .NET selbst ganz wesentlich COM verwendet. Und originellerweise basiert eines der neuesten "Kinder" von Microsoft, nämlich WinRT, auf COM.

[nn]

Chew-Z schrieb:

COM ist in Windows derart tief verwurzelt,

Das ist gleichzeitig Vor- und Nachteil. Wenn man Qt benutzt, um portabel zu sein, ist COM eher ein Problem.

Chew-Z schrieb:

Und originellerweise basiert eines der neuesten "Kinder" von Microsoft, nämlich WinRT, auf COM.

"Kind" ist eine gute Beschreibung. Es ist quasi das gemeinsame "Kind" von COM und .net. Und C++/CX ist quasi ein C++ mit eingebauten COM-Schnittstellen.

[Chew-Z]

Wenn du nicht auf Windows festgelegt sein willst/musst bleibt eigentlich nur noch CORBA übrig.

[ewewew]

RHBaum schrieb:

- Wir wollen einen Buildwerver aufsetzen ... Durch die unterschiedlichen Abhaengigkeiten, also QT versionen, Visual Studio versionen und von uns noch einigen Build-Varianten komm ich auf eine maximal Mögliche Anzahl von Kombination von 4 (uns bekannte Qt versionen im EInsatz) * 3 (uns bekannte Visual Studio Versionen im Einsatz) * 4(unserer Varianten) * 2 (Release Debug Build) = 96 Tragets !!! pro (von usn nach aussen gegebenen ) Modul und Version !

Das ist doch schon mal ein guter Grund, warum kein Qt in den Interfaces für Kunden sein sollte. Da spart ihr euch schon mal ne Menge Targets.

[RHBaum]

Ach ja, was ist an dem Buch, was ich empfohlen habe, so schlecht, dass es hier ignoriert wird ? Es behandelt ziemlich genau diese Thematik, auch im Kontext von Patterns.

Ich ignorier es nicht, aber ich kenn den Inhalt noch ned, also kann ich nix drueber sagen ^^
Aber ich arbeite dran (leider soll die Kindle-version ziemlich verhunzt sein, was das layout betrifft, deshalb gehts ned so schnll ^^)

Das ist doch schon mal ein guter Grund, warum kein Qt in den Interfaces für Kunden sein sollte. Da spart ihr euch schon mal ne Menge Targets.

Nein, fuer unsere Entwickler und unsere Project-Manager ist es ein Grund ein Tool zu suchen, was diese Anzahl an Targets managen kann !
Auf die Idee, das dieses problem hausgemacht ist, kommen sie ned

Das beste was passieren kann, ist das nen Werkstudent engagiert wird, der nen Build-tool raussuchen soll, was diese Anzahl an Targets schafft und ueber extensives Scripting so anzupassen ist, das es mit unserem System funktioniert.

Das schlimmste was passieren kann, das wir die externen(innerbretrieblich, aber von anderen Abteilungen) Anforderungen nicht bedienen koennen, und den anderen Abteilungen die Kosten fuer eine angepasste version fuer Ihre Umgebung aufgedruckt werden. Bis irgendwann mal nen Chef ans Ruder kommt, der die Sache hinterfragt und dann die richtigen Konsequenzen zieht ...

Ciao ...

[RHBaum]

Nachtrag nochmal:

So schlimm wie hier geschildert siehts ja eigentlich doch ned aus.
Gegenüber dem Zustand früher tut sich ja etwas, meiner Ansicht nach auch in die richtige Richtung. Nur iss das ja wie immer sehr schwer und zäh

Ich tu mich eben nur schwer solche Design Themen durchzudruecken und zu begruenden, ohne den entsprechende fachlichen Refernzen.
Ich bin halt nur einer von 5 Programmierern, zwar seit 10 Jahren im Projekt, aber damit auch ned am längsten.

Die anderen Programmierer sind eher mehr ... sagen wir mal praxisorientiert. deren Welt sind eher die GUI's und was es fuer tolle Bibliotheken dafuer gibt.
Während ich mehr so auf die c/c++ Style Themen druecke, und mehr die unsichtbaren Dinge im Hintergrund mache, und Bibliotheken fuer die anderen baue. Wenn was performant sein muss, landets meist auch bei mir ...

Ciao ...

[nn]

RHBaum schrieb:

Ach ja, was ist an dem Buch, was ich empfohlen habe, so schlecht, dass es hier ignoriert wird ? Es behandelt ziemlich genau diese Thematik, auch im Kontext von Patterns.

Ich ignorier es nicht, aber ich kenn den Inhalt noch ned, also kann ich nix drueber sagen ^^

Sorry, ich meinte eigentlich nicht dich damit. Es ging mir eher um die Antwort, dass das in jedem Patternbuch stehe, was meiner Meinung nach so nicht stimmt.
Was das Buch selber angeht, habe ich auch die Printversion. Die ist vom Layout ok und vom Text her gut zu lesen.

Im Zusammenhang mit dem genannten "Patterns kompakt" würde ich dir gerne noch ein anderes Buch vom gleichen Autor empfehlen, den "Knigge für Softwarearchitekten".
http://www.gernotstarke.de/publikationen/page5/index.html

Ist nur ein winziges Büchlein, behandelt auch nicht die technischen Aspekte, sondern eher die menschlichen und organisatorischen Faktoren.

Mach mal bei Amazon den "Blick ins Buch". Möglicherweise wird die Lektüre dich weiterbringen.