Constructor should be public.

[Frederic Da Vitoria]

Hello,

What is the rationale for this hint? I understand that usually constructors and destructors are public, but why *should* they be public?

[User137]

Constructors are called from the main program and other units. If you wish to execute some modular thing within class, you can make private procedures and call them.

[Dibo]

What is the rationale for this hint? I understand that usually constructors and destructors are public, but why *should* they be public?

So how do you want create object if its constructor is hidden?

[Blaazen]

If you have two classes (TMainClass and TSubClass) in one unit and TSubClass is used only inside TMainClass and nowhere else, then you really don't need public constructor. But it is a special case. In such case you can use nested class.

[Frederic Da Vitoria]

What if I don't want other units to create and destroy objects? Of course, if a unit contains the description of only one class, the constructor and destructor will necessarily be called from outside, so that they must be public. But I often build units with an "elementary" class and a specialized container class. Then it makes sense to make the constructor private: the container class is the only in charge of creating or destroying instances, but the instances may be otherwise manipulated by the rest of the application. This way of doing things helps me ensure I don't forget to destroy an instance.

Edit: I meant "container" in the technical sense, like a TObjectList descendant.

[User137]

Anything you define in the interface section can be seen from other units that use it. Another way to make privacy, is to split some types in a sub unit. If on the otherhand these sub-classes would need something from the others aswell, you can avoid circular references by making yet another unit for common types.

Kind of like:
TApplication
- inherits from CustApp.TCustomApplication
- - inherits from classesh.TComponent
+ many other units that includes classesh for TComponent. LCLClasses.TLCLComponent for specialiced components, and so on.

[marcov]

What if I don't want other units to create and destroy objects?

You can't anyways There is always a default constructor and destructor..

Closest is to declare an interface with all externally callable symbols, and only export that, and keep the class in the implementation
 

[Frederic Da Vitoria]

All those years, since Delphi didn't complain, I thought my idea worked. I now understand that I can't hide the constructor or destructor, because you can't reduce the visibility of a member. If the ancestor Create was public (which is the case for all TObject descendants), then there is no way you can hide it. What I achieved is actually worse: if by any chance I called Foo's Create from outside the unit, I would unknowingly be directly calling TObject's Create and not Foo's Create.

Thanks to Lazarus for showing me that my trick was useless. And thank you all for showing me to see this was indeed so.

[taazz]

Here is a fast patch that does what you want

Code: [Select]

Unit Unit1;
interface
uses Classes, Types, ......
Type

  TMyInternalyCreatedObject = Class
  Protected
    Constructor PrivateCreate;
  public
    Constructor Create;
  end;

implementation

constructor TMyInternalyCreatedObject.PrivateCreate;
begin
   Inherited Create;
end;

Constructor TMyInternalyCreatedObject.Create;
begin
  Raise Exception.Create('This object is only for internal use.');
end;



[Frederic Da Vitoria]

Yes, I was thinking of something like this. My idea was using assertions, raising an exception is probably best, because I can't be sure I will test all possible combinations, the issue might arise during a user run.