Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Delphi - Declaring in class or not?

Tags:

scope

delphi

Just recently, probably because I've been maintaining some old code, I've started to look at how / why I do things. As you do.

Most of my Delphi programming has been picked up in house, or from examples scattered across the web or manuals. And in some things are done just because "that's how I do it"

What I'm currently wondering about is Declaration, of variables, procedures, functions, etc.

When I am working with a form, I will place all my procedures and functions under public or private. Whilst I will try to avoid global vars and constants will generally go under var or const, either in the interface or implementation, depending on where they need to be called (occasionally though they will go in public / private)

Otherwise, if its just a unit I will declare the procedure in the interface and use in the implementation. Some of the code I've been maintaining recently has no interface declaration but instead has everything properly ordered with calls after procedures...

Is there a correct way to do this? Are there rules of what should / should not go in the class? Or is it a style / when you started thing?

Edit to add

My question is not about whether a declaration of a procedure goes in private/public but whether all declarations in a TForm Unit should go in one of these. Similarly should var / const be in one or the other?

Further clarification

I understand that not declaring in interface, or declaring in public/private/etc affects the visibility of procedures/functions to other units in my applicaiton.
The core of my question is why would i not want to declare? - especially when working in a form/unit when placing in private is much more explicit that the thing declared is not available to other units...

Cheers Dan

like image 870
Dan Kelly Avatar asked Dec 30 '22 04:12

Dan Kelly


1 Answers

Everything that can have a different value depending on the concrete instance belongs to the class, i.e.

TDog = class
strict private
  FColor : TColor;
  FName : String;
public
  property Color : TColor read FColor write FColor;
  property Name : String read FName write FName;
end;

Color and name are clearly attributes of each dog (and each dog will have other values here).

General rules:

  • Fields belong in private (visible in this class and in this unit) or strict private (visible only in this class)
  • If you need access to fields from other classes, create a public property. This gives you the freedom to change the simple field access to a more sophisticated getter / setter method lateron without changing the interface of your class.
  • Everything should be as local as possible. If private is enough, there's no need to make it protected (visible in subclasses too). And only make those things public that you really need from the outside.
  • Forms: only those things that you want to be stored in the DFM file should be published.
  • Put as much as you can in the implementation section and as little as you can in the interface section. This is also true for uses clauses.

You might be confusing the term global variable. If it's declared in a class it's not a global variable (even if declared public). Global variables (which you correctly consider good to avoid) always go in a var section either in the interface or the implementation section (which is preferrable following the general rules above)

like image 141
jpfollenius Avatar answered Jan 18 '23 22:01

jpfollenius