What are the advantages of using namespaces in Delphi?

5

From the 2009 release of Delphi (if I'm not mistaken) came the namespaces . I would like to know, in a simple example if possible that illustrates a case of advantage, what would be the advantages of namespaces in Delphi?

Accounts.cs file :

namespace Projeto.Forms {
    public class ContasForm : Form {
       ...
    }
}

Archive Shopping.cs :

namespace Projeto.Forms {
    public class ComprasForm : Form {
       ...
    }
}

Client.cs file :

namespace Projeto.Forms {
    public class ClienteForm : Form {
       ...
    }
}

In a fourth file, MainForm.cs , I would have access to all three classes only by references namespace :

using Projeto.Forms;

namespace Projeto {
    public class ContasForm : Form {
       private ContasForm contasForm;
       private ComprasForm comprasForm;
       private ClienteForm clienteForm;
    }
}

In Delphi this does not happen:

File Project.Forms.Accounts.pas :

unit Projeto.Forms.Contas;
interface
uses ...
type
  TContasForm = class(Form)
  ...

File Project.Forms.Compras.pas :

unit Projeto.Forms.Compras;
interface
uses ...
type
  TComprasForm = class(Form)
  ...

File Project.Forms.Customer.pas :

unit Projeto.Forms.Cliente;
interface
uses ...
type
  TClienteForm = class(Form)
  ...

Finally, when you want to refer to them in Project.Forms.MainForm , do the following:

unit Projeto.Forms.MainForm;
interface
uses Projeto.Forms.Contas, Projeto.Forms.Compras, Projeto.Forms.Cliente;
type
  TMainForm = class(Form)
  ...

No you can do something like Projeto.Forms and from there you have access to all three classes. Much less is allowed in Delphi to have more than one file with the same name.

The only way I saw of having such a benefit would be to manipulate . Example:

Create a unit with the name Project.Forms.pas :

unit Projeto.Forms;
interface
type
  TContasForm = Projeto.Forms.Contas.TContasForm;
  TComprasForm = Projeto.Forms.Compras.TComprasForm;
  TClienteForm = Projeto.Forms.Cliente.TClienteForm;
...

And then make the reference as you had quoted, uses Projeto.Forms; and then have access to the three classes.

Well, I do not know if this would have consequences and, of course, it was just to illustrate.

So, I ask: What are the advantages of using namespaces in Delphi?

I ask for a small example just to illustrate. Thanks!

    
asked by anonymous 03.06.2015 / 15:02

1 answer

5

Advantages of using namespaces in Delphi

  

Namespaces in Delphi are meant to organize units and types in a logical way.

     Namespaces also serve to provide a global unique identifier for a type or unit, so we can have more than one type or unit with the same name in the same project.

In a large system, it is not uncommon for different units or types, from different contexts, to have the same name naturally.

For example, a product in stock may be a distinct entity of the product on the sales front end (see DDD - bounded context ). Namespaces allow us to actually call both "Product" entities with different namespaces, providing a more expressive nomenclature and closer to the business, without having to forge prefixes and suffixes to differentiate units and types from different contexts.

In addition, there is more clarity in calling a unit of Business.Estoque.Produto than BusinessProdutoEstoque .

Differences between Delphi namespaces and C Sharp namespaces

An important difference between C # namespaces and Delphi namespaces is that in C # they group types, and in Delphi they group units and units are grouping types (each unit is a source code file).

So in C #, to bring into context all kinds of a namespace, we do so:

using Business.Estoque.Produto;

Now all types of this namespace that are referenced by the project will be immediately available in context.

In Delphi, the above command (would be uses instead of using ) would be referencing the Location.Product unit of the namespace < in> Business.Estate , bringing to context all the types declared in this unit.

Similarity between Delphi namespaces and Java namespaces

If in the project the practice is to declare only one public type in each file, in this aspect Delphi namespaces are more similar to Java namespaces (where they are called packages ), because in Java the source code has the name of the public class contained in it, and the default is to reference not a namespace in order to bring all its types into the context, but to reference each of the classes that one wants to bring to the context.

In Java, the import Business.Estoque.Produto command brings to the context only the Product class, such as in Delphi would be bringing only, say, a class called TProduct (contained in unit Product ).

Here, Java has a feature that Delphi does not have. In Java there is the option of bringing all types of namespace into context at once:

import Business.Estoque.*;

In the above command, not just such a Product class but also all classes of the Business.Estoque namespace will be available in context. Delphi does not have this feature, so each unit of the Business.Estoque namespace would have to be referenced explicitly, eg:

uses Business.Estoque.Produto, Business.Estoque.Produto.Categoria,
    Business.Estoque.Inventario;

Conclusion

Namespaces in Delphi have the same goal as in C # or Java: logically organizing the project, with the benefit of being able to have global unique identifiers for types or units with equal names.

The most important difference is that while in C # or Java a namespace (in java, package ) groups types, in Delphi a namespace groups units and the units group types.

In Java, it is common practice to explicitly reference each type, but it is also possible to reference all types of a namespace at once using the wildcard *. In Delphi the only option is to explicitly reference each unit.

While not simplifying reference to types in context (do not allow referencing types contained in multiple units at once), namespaces in Delphi still offer the advantage of logically organizing the project, allowing more expressive names for units and types. / p>

For example, instead of having units and types with names like CategoriaCliente , CategoriaProduto , CategoriaFrete ... I can have Vendas.Cliente.Categoria , Estoque.Produto.Categoria , Transporte.Frete.Categoria . p>     

12.06.2015 / 19:30