Re: Never ever use a raw pointer when a smart pointer can do the same
job
On Aug 21, 5:25 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Aug 20, 7:33 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* Noah Roberts:
Alf P. Steinbach wrote:
* Noah Roberts:
If the new class changes nothing wrt. client code, then there
is absolutely no reason to foist a replacement on the client
code.
Huh? The behavior can easily depend on various elements in
the external environment. Under X, for example, it is
frequent to support several look and feels, determined from
an environment variable, a configuration file or whatever.
The immediate client of the code doesn't know or care about
the look and feel, it wants a button. So your factory
function returns a button with the correct look and feel.
The button example is a bit misleading since there are other
concerns that can force a factory function.
And? It's obviously not the only example, and there are just as
obviously other possible solutions. It is, however, a
reasonable case where one would provide a factory function which
returns an object of a derived type unknown to the client code.
Still, there's nothing that prevents direct 'new' of a class
'Button', where the look and feel can depend on configuration,
say. In fact I have a class 'PushButton' that does this, and
it required no special support from me to get it to do that: a
factory function would just be more code, no-purpose code, and
anyway, is clearly not required.
Not required, perhaps, but it is certainly the simplest
solution. In particular, in the cases I've used it, the factory
function is in a dynamically loaded object; you don't encumber
the application with all of the look and feels, only with the
one it used.
For that matter, I use a similar strategy for handling
differences between Windows and Unix: for reading
directories, for example, if I'm under Unix, the necessary
data is a DIR*, under Windows, a WIN32_FIND_DATA, but
neither appears in the class definition the client sees.
Consider normal code, this from a Boost documentation example:
bool find_file( const path & dir_path, // in this directory,
const std::string & file_name, // search for this name,
path & path_found ) // placing path here if f=
ound
{
if ( !exists( dir_path ) ) return false;
directory_iterator end_itr; // default construction yields past-the-en=
d
for ( directory_iterator itr( dir_path );
itr != end_itr;
++itr )
{
if ( is_directory(itr->status()) )
{
if ( find_file( itr->path(), file_name, path_found ) ) return true=
;
}
else if ( itr->leaf() == file_name ) // see below
{
path_found = itr->path();
return true;
}
}
return false;
}
Would you really have the 'directory_iterator' allocated by a
factory function, with the client code dealing with a pointer
to the iterator, as Noah, and now (I think inadvertently) you,
argues that it should be, or that it's natural to do?
No. I use a different model---the directory is a container, and
provides the iterators (which are portable, since they are
declared as friend, and refer to the container to do the work).
But I think you're right with regards to your point---the
factory function certainly isn't visible to the client. (The
Directory container-like object basically uses the compilation
firewall idiom, with the factory function used to provide the
implementation class. And now that I think about it... The real
reason why a factory function is used has more to do with the
way errors are handled than with hiding the implementation
details.)
Thinking about it, I think that most of my uses of factory
functions are more or less hidden from the client code. Those
that aren't generally take an argument which will determine the
actual type returned, and are concerned with loading dynamic
objects---the client code can't just do "new
ISO88598_1_Translator" because 1) it might be necessary to load
the code first, and 2) it might be that there is no such class,
that the call to the factory function getCodeTranslator( "ISO885901" )
actually returns "new SingleByteCodeTranslator(
translationTableISO8859_1 )" (given that every single byte code
translates more or less in the same manner).
(This is an actual example. The code translators are all
immutable objects, and there is a map which contains pointers to
the ones that exist. So the factory function first looks in the
map, to see if an entry is already present, and if not, it
loads the appropriate dynamic object, calls its factory
function, and inserts the object into the map before returning
it.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34