Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>Especially I'd like to do a better separation between interfaces, the public face of the components, and their implementations in behind.</p> </blockquote> <p>I think what you're looking for is the <a href="http://en.wikipedia.org/wiki/Facade_pattern" rel="nofollow noreferrer">Facade</a> pattern:</p> <blockquote> <p>A facade is an object that provides a simplified interface to a larger body of code, such as a class library. -- Wikipedia</p> </blockquote> <p>You may also want to look at the <a href="http://en.wikipedia.org/wiki/Mediator_pattern" rel="nofollow noreferrer">Mediator</a> and <a href="http://en.wikipedia.org/wiki/Builder_pattern" rel="nofollow noreferrer">Builder</a> patterns if you have complex interactions in your classes.</p> <p>The <a href="http://gotw.ca/gotw/024.htm" rel="nofollow noreferrer">Pimpl</a> idiom (aka compiler firewall) is also useful for hiding implementation details and reducing build times. I prefer to use Pimpl over interface classes + factories when I don't need polymorphism. Be careful not to over-use it though. Don't use Pimpl for lightweight types that are normally allocated on the stack (like a 3D point or complex number). Use it for the bigger, longer-lived classes that have dependencies on other classes/libraries that you'd wish to hide from the user.</p> <p>In large-scale projects, it's important to not use an #include directives in a header file when a simple forward declaration will do. Only put an #include directives in a header file if absolutely necessary (prefer to put #includes in the implementation files). If done right, proper #include discipline will reduce your compile times significantly. The Pimpl idiom can help to move #includes from header files to their corresponding implementation files.</p> <p>A coherent collection of classes / functions can be grouped together in it's own namespace and put in a subdirectory of your source tree (the subdirectory should have the same name as the library namespace). You can then create a static library subproject/makefile for that package and link it with your main application. This is what I'd consider a "package" in UML jargon. In an ideal package, classes are closely related to each other, but loosely related with classes outside the package. It is helpful to draw dependency diagrams of your packages to make sure there are no cyclical dependencies.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload