Okay, I want you all to notice that in my previous post about the use of Create, I was pretty careful not to say “Never call Create”. And near the start I said “For the most part”. So let’s be clear – just as I didn’t say “Never ever call FreeAndNil”, I’m not saying “Never call Create”. And while I am at it, I didn’t say “Use interfaces everywhere” either. Those of you who are accusing me of saying so are wrong. Incorrect. Inaccurate. You should be ashamed and you should correct yourselves. You should also read more carefully and think more precisely.
Enough about what I didn’t say. What am I saying? I’m saying “Architect your code so that you avoid calling Create, because doing so causes problems”.
Problem number one is that your code becomes difficult to test. This is a fact: When you call Create – when you create more than just an instance of a specific instance of a specific class – you are tightly coupled to that class and it’s entire dependency graph. (If you don’t know what a dependency graph is, you can find out more here.) Some classes have huge dependency graphs. That is, the creation of that class cause a cascading of creation of other classes which can initiate any number of things: Connections to databases, locking of files, attachment of limited resources like turnstiles or cash registers – who knows what?
Classes that have dependency graphs are classes that should not be manually created, but instead should be created by a class that can control if and when that class is created. The creation of such classes should be definable and controllable. They should be referenced by an abstraction and they should be created in a configurable way. If you want to test the dependent class, then you can have your system create a mock instead of the real thing. If you call Create on that class, you can’t do that.
How should we refer to these types of classes – classes that have dependency graphs of any sort? Let’s refer to them as “complex classes”. (I looked for the commonly accepted term here, and couldn’t seem to find one. I haven’t the slightest doubt that one of you will tell me what the “right” term here is. I’ve seen the term “volatile” used, but I don’t like that because of the keyword volatile that some languages use.) So for the purpose of our discussion, a complex class is one that has a dependency graph; it’s a class that, when created, brings in other external dependencies. Sometimes those external dependencies are easy to define, and sometimes the dependency graph gets so complex it is hard to know what is happening exactly when that class is instantiated. For instance, think of TForm. When you create TForm, holy mackerel – a long, complex host of other things are being allocated – Windows handles, other VCL classes, fonts and this and that and the TKitchenSink. TForm is most definitely a complex class.
But, what about something like TStringList? TStringList has, as far as I can tell, no real dependency graph. Create one of those, and you really aren’t creating a host of external dependencies. TStringListis basically self contained. It is a known, limited entity. (Look at it’s constructor and the constructor of TStrings. It basically doesn’t create anything, so it really can’t have any dependency graph.) It can be created without worrying that you are going to end up calling some charge-money-every-time-you-use-it web service. It’s simple, clean, and limited. It’s not a complex class. It’s a simple class.
So, to answer the question posed in the title of this post – you can (and should) call Create on what I’m calling simple classes. Generally, these will be classes defined in the RTL that clearly are stable or simple in that they don’t have dependencies that are non-deterministic, unknown, or complex. Classes like TStringList, TStringBuilder, TList, the classes in Generics.Collections.pas, and many others are examples of classes that you should feel fine about creating. These classes are know and proven by virtue of being part of the RTL. You probably have many similar classes in your own library – classes that you have bathed in unit tests so you know that they are isolated, stable, and simple. You can determine the complexity of such classes by looking at the constructor of a given class. (And note: The use or lack of use of Create in those classes indicates whether they are complex or simple. Hmmm.)
You should feel safe creating such simple classes because you know that you aren’t dragging in the TKitchenSink when you create them.
So that should answer the question, eh?