Less is More - Dynamically typed languages

When I was in the university I learned that strongly typed languages should be preferred since they avoid the programmers from using a certain variable in way that it was not meant to.
If I declare "string name;" I know this will accept only strings and will prevent a programmer from assign a number or a boolean value on it.

But this seems to be a false concern with the success of other languages such as Python and Ruby.
This programming languages are now used to each time more complex software and nobody is complaining about their "dynamic" features.

The goal the new development tools are trying to achieve is how can I do my software faster in a clean and organized way. Less is More !

Packages: A Tool to Organize Classes

One of these days I was taking to a work colleague about what should be the package (a.k.a. Namespace) of a certain class. Not rare there is a small debate about it. Should the class WorkerRiskActivity belong to the Health package or to the Activity package ? And so on ....

Although it may sound a useless discussion it has been proven ( at least to our organization ) that this kind of worry is healthy specially in the long term.

I can enumerate the following advantages in using good packages for classes:

• It breaks the complexity of hundreds of classes in blocs composed by few classes just like folders for files.

• It gives a clue for developer about what is the role of this class in the system.

The fully qualified nameFinance.Sevices.DebtManagement tell you what the class actually does.

• It organizes the logic architecture of your software. This is specially useful for layered architecture where the classes are organized according to the class role.

Organizing classes can also be confusing. In order to avoid wrong classification, the following anti-patterns are listed below:

• Packages with vagues names
  

One of the traps that should be avoided is to create packages with too vague names such as General, Etc or Miscellaneous. This names are going to be used by lazy developers to place classes they don't want to think about how to classify to the right package.

• Too much debate about packages
  

In the other hand, organizing classes in packages should not give rise to a long debate. If a class was placed in the wrong package, a code refactoring can solve the problem later.

• Package-by-layer

Although it can sound perfectly reasonable to have classes organized by layer. Actually this kind of packages can be harmful since it is no more possible determine what kind of permission a specific package can have since this package actually has all kinds of classes from varying parts of your system that don't relate to each other. The preferred way to use packages is to organize them by feature as it can be seen in all examples listed in this post. In fact this is not a "personal way" of modeling packages, this is the original purpose of a package.
Thus the package Finance has all classes that compounds a financial application including its UI layer, services and the problem domain classes.

Why developers do not like to model the Real World ?

Years ago the concept of roles, real world modeling, reusability and many others were not known. People with different roles were modeled in different entities ( tables or classes ) as if they were different things. In many database models such as the Northwind example we would find a table for Clients, another table for Vendors, a table for Employees and so on.
This kind of approach leads to data ambiguity since a Person can be an Employee in some occasions and a Vendor in other occasions or this Person can be a Client. So if a Persons must have his address, name, contact, etc. modified, this change must be reflected in several other tables. This business rule or better this developer rule should be remembered by anyone responsible for developing a system that could modify the data in one of these tables.

The approach changed but recently I was taking a look at a Class Diagram from a work colleague and it called my attention that he modeled the Accounting Role as Class Accountant.
It is not uncommon to see the same pattern when modeling peoples roles in many other Class Diagrams or even Data Diagram ( Entity Relation ) . Many developers usually create a class (or table) for each role like this:

It is not hard to see that as long as the system grows, more roles are needed. The additional classes multiply in the Class Model making it each time more complex to understand.

Interestingly there is an Analysis Pattern that deals with people's roles problem by providing a more elegant Class Modeling like this:
Now the roles are better organized and if more roles are needed they can be added to the Class Hierarchy. And that is all right.

This could be a perfect solution to the problem but let me ask you a question.
Do the roles really exist in Real World ?
I mean, imagine there are no computers and information systems, how do you do to know someone's role in your organization ? Do you ask: What's your role ? Off course not.

If you are working for a Health Care Company, for example, in order to check if "Jack" is a doctor you ask him his Doctor License ( or Medical License or whatever document is used in your country ). To work as a Doctor, Jack must have this document (or license). He may not carry this document with him maybe it may not exist physically but there is some sort of license or document that grants him the permission to work with others people's lives.

The same happens for accountants. Accountants do not work with people lives but in many countries they must have a document or license that enables him or her to do their jobs.
In order to know if someone is an accountant, you just have to check if he has an Accountant Registration ( or any name you prefer ).

Using document or license ( think of licenses and document as the same thing ) metaphor instead of roles gives you a more natural representation of your business rules. If the Class Diagram is more naturally represented by using Real World characteristics it is also more intuitive. Thus it can be better understood and learned by newcome developers or other developers in a large enterprise system. Check out the Class Diagram below:

The Class Diagram above shows a Person with his/her documents the way as it is in the Real World. If a another Document Type is needed it can be added to the hierarchy just like the prior class diagram.

My First Big Enterprise System with NHibernate

We just finished to deliver our first big .NET system with a 4-Layered Architecture and domain objects. The proof-of-concepts is done also for big systems.

Because we use a 4-Layered Architecture, the same business rules describe in the Task Layer (or Service Layer, as you wish) are applied to both the desktop and the web versions of the application.

NHibernate has also proven its value showing that it has enough performance for any kind of systems. I am anxious to start building other layered object-oriented systems like this.

Delphi for OO Programmers

I just came from a presentation about Borland products.
One of the speakers were showing a piece of Delphi code to explain his idea about object oriented programming and multi-tiered application for Delphi.

The Delphi syntax for declaring classes is very bad. Instead of using a syntax similar to what we can find in C++, Java or C# there were strange reserved words. For declaring a Person class, one must code:

type Person = class
  private
    name : string;
  end;
end;

To inherit from a Person it should be something like:

type SpecialPerson = class(Person)
  ......
end;

After that in the beginning, the speaker said the "some people" say that OO programming is about, for example, creating a Person class, adding methods to manipulate data, using the instance to perform business logic and then saving to the database. He said that is not the only way and this is just the Java way to build OO systems.
At this point I turned off my attention from the presentation for a while and I started wondering if there are other ways to build OO systems.

What he was calling OO programming was a class with lots of static methods responsible for executing a piece of the system. There was a method for inserting a person, erasing a person, calculating a salary, inserting a document, etc.

Well I would say this is a Service Class but that doesn't mean that this is a OO system. A lot of people say that because they have declared a class or interface they can assume they are programming using the OO paradigm. A paradigm is not only using objects but a way of thinking and an object oriented system is one that was designed as a collection of objects exchanging information between them by using methods.

I have heard a lot of people saying that and it is almost rare to find someone that really understans what OO means. At least here where I live in Brazil. I don't think the programmers must know about OO paradigm but they must admit when they don't know about a subject and should give the adequate name to the methodology they are working with. In that case above of the Delphi guy, I would say procedural paradigm.

I also got to the conclusion that a programming language like Delphi was not meant to use OO although it supports this paradigm.

OO Paradigm Popularity

As far as I know OO has existed since the 70's. For a long time, OO was mainly used for academic projects. In the meantime relational databases gained popularity between comercial computer systems and so the relational model.
The relational model has also evolved gained popularity since it presented a concrete solution to the problem of how to store data of a business model.

With the rise of Java Programming Language, OO became much popular since it motivates the programmer to use this paradigm.

One of the most important characteristics of the OO paradigm for enterprise applications is that the data and the functional aspects of a business model could be abstracted. Thus OO paradigm offers a higher level of abstraction compared to the relational model however that didnn't turn itself into a practical advantage for comercial system.

Relational Databases are responsible for almost all data storage in computer systems while OO Databases ( not talking about Object-Relational Databases like Oracle ) are not sufficiently mature yet and although it was easier to build more complex software an old problem still persisted which is the OO paradigm and the relational model mistmatch problem deeply explored by Scott W Ambler.
( http://www.agiledata.org/essays/impedanceMismatch.html )

This impedance mismatch use to consume a lot of time from OO programmers. For example, a line in a Person table in a relational model is represented as a Person object. Before in order to do that OO programmers had to program a persistence layer by hand. Besides time consuming it was also a complex task. These reasons were enough to put OO away from the comercial software market for several years.

The Object-Relational-Mapping Tools (ORM Tools ) addressed this issue more productive way. With these tools the columns of a table in the relational model were mapped to an attribute in a class in the OO model. These mappings can be done in a XML file, in a separate class or by using annotations. The most stable and well-documented so far is Hibernate.
( www.hibernate.org )

Whatever these mappings are described these tools made it possible to use OO in Enterprise Applications Projects. It was not necessary to spend so long time to implement object persistence and it was also possible to use OO in legacy relational databases.

There are even tools that generate the class code in Java or .NET and the mapping code from the database schema like MyGeneration.
( http://www.mygenerationsoftware.com/portal/default.aspx )

Interestingly there lot of articles out there saying that there is no evidence proving that the OO approach is a an advantage over the relational programming and not a long time ago some authors used to say that OO in Enterprise Applications was something impossible.

In my opnion OO offers advantage in a long term since the business model is gradually represented with a higher level of abstraction.