Breaking Information Hiding in C++

Almost every object-oriented programmer is familiar with the concept of information hiding. Actually, lots of them get confused with the terms encapsulation and information hiding. So, before we talk about information hiding itself, let me explain the difference of both terms:

• Encapsulation is the public interface that defines how an object can be used, and how its data is derived.
• Information Hiding is the principle of hiding design decisions, preventing external objects from using the derived data.

Now let’s take a look in a real sample. The code below shows a classic header file, corresponding to a Point class. Note that class’ members are protected against modification, since they are declared as private and no setter methods were provided. The class data is also encapsulated into the Point interface, which defines how Point objects are used, through its constructor and getter methods.

Point.h

A very common issue when using a third-party API is the need of changing private members value when running some tests. However, if no setter methods exist, the change can’t be made, right? Well, in C++ things are pretty different. When using pointers, you’re working directly with memory addresses. So if we create pointers that make reference to private member’s address, we can manipulate its value. Look at the code below.

main.cpp

Note that I’m using an integer pointer, which is an array of integers. If we come back to Point class definition, we will see just two integers. Therefore, in respect with memory manipulation Point class is similar to an integer array. In other words, array[0] is the same of point->x since both read int values (4 bytes in win32 platform). When doing the pointer attribution and the explicit cast, we’re just pointing the integer array to the first memory address of the object. Changing its value will affect the memory content, it means: the object private member.

I know that this is a little bit weird, but it works perfectly. To looks like more acceptable, we could create a new class, similar to Point class signature, and manipulate its members, but in fact working with the Point class member variables. Here is the code that illustrates this behavior.

MyPoint.h

main.cpp

Now, be free to change private members wherever you want.

See you,

[]’s

Fernando

Principles of Package Design

Agile Software Development is really an incredible book. After reading it, a lot had been talked about the Object-Oriented Principles on this blog (here and here). Today, I’ll be talking about another section of the book, which introduces principles used to maintain high package cohesion and a desirable package dependency, known as Principles of Package Design.

Packages are used to organize larger projects. More than this, they are containers of classes used to manage the development and distribution on software. Package’s goal is separate classes in an application according to some criteria. However, classes often have dependencies on other classes, creating package dependencies relationships. To help manage this situation, some principles were created to govern the creation, interrelationship and use of packages.

The three principles in sequence are related to package cohesion, useful in deciding how to partition classes into packages.

The Reuse-Release Equivalence Principle (REP): the granule of reuse if the granule of release

REP states that anything that we reuse must also be released and tracked. Reusability is not only the creation. It comes only after there is a track system in place that offers the guarantees of support that reusers will need. Since reusability is based on packages, if some software is going to be reused, then it must be partitioned in a convenient structure for this purpose, so all classes in a package become reusable by the same audience.

The Common-Reuse Principle (CRP): the classes in a package are reused together

CRP helps in deciding which classes should be placed into a package. This can be determined by reuse characteristics. Classes that tend to be reused together should be placed in the same package. Remember: if you reuse one class in a package, you reuse them all. Although the CRP tells us what classes put together, it also says what classes do not put in the same package. If a class depends on another class in a different package, it depends on the entire package. Every time the used package is released, the using package must be revalidated and rereleased, even the change was made in a different class that the using package depends on. Therefore, CRP also says that classes which are not tightly related to each other should not be in the same package, so every time I depend on a package, I depend on every class in that package.

The Common-Closed Principle (CCP): a change that affects a package affects all the classes in that package and no other packages.

This is the same as SRP, but applied for the packages context. Such as classes should have just one reason to change, CCP states that packages should not have multiple reasons to change. It’s preferable that changes occur in just one package rather than distributed along the whole system.

Now, we are going to take a look at principles related to package relationship and dependency.

The Acyclic-Dependencies Principle (ADP): allow no cycles in the package-dependency graph.

Package cycles create immediate problems, and the most obvious one is when you have to release a package that was modified. In order to release the package, it must be compatible with all other packages that it depends on. A cycle in your package-dependency graph makes release harder since you increase the number of packages that you have to be compatible with. For example, take the Figure 1 and Figure 2. To release package C in the first situation we must be compatible with package E and F. However, in the second case we also must be compatible with package A, B and D. Even worst, if you want to test package C, we must link and build all other packages in the system, instead of just two of them.

To break the cycle, two solutions are suggested:

1. apply Dependecy-Inversion Principle.
2. create a new package between C and A, and move the classes that they both depend on into that new package.

The Stable-Dependencies Principle (SDP): depend in the direction of stability.

Stability has nothing directly to do with frequency of change, but to the amount of work required to make the change. In software, package stability is measured in number of classes inside this package that depend on classes outside this package and number of classes outside this package that depend on classes within this package. Thus, a package is called instable if it is easy to change, in other words, just a few or none packages have dependency relationship with it. A package is called stable if it is hard to change, or a lot of classes outside this package depend on it. The book also brings a method to calculate stability metrics, but I’ll not be such detailed. Just have in mind that a good design contains some instable package and some stable package. Instable packages are on top and depend on stable packages at the bottom, just shown below.

The Stable-Abstractions Principle (SAP): a package should be as abstract as it is stable.

This principle states that a stable package should also be abstract so that its stability does not prevent it from being extended, and an instable package should be concrete since its instability allows the concrete code within it to be easily changed. Thus, stable packages consist of abstract classes and instable packages of implementations classes.

Conclusion

After some posts of OOP, we already know how to create a good class design. However, in big systems, classes are separate into packages which corresponds a very important part of the system’s release and deploy. So, a new concern is how to divide classes between packages and maintain the system’s consistency. In this post we introduced six principles explained in Robert Martin book which help us in solve a lot of package design problems. You can find a lot of more information in the book, which I strictly recommend.

See you,

–
Fernando

Generic DAO with NHibernate and Autofac

Data access is one of the most important design decisions in software development. Depending on how you design your data access classes, every single modification causes cascading changes throughout your project. Imagine you have a lot of persistent data objects to manage and, for example, you have to change your database. This transition must be done without modifying the source code of your persistent classes. Other problem happens when you add more persistent data collection classes to the system. Of course, you won’t be happy if every time a new basic class is added, a new CRUD class is needed. The last point is programming in respect with the OOP, in other words, programming for the abstractions and not for implementations, with low coupling and high cohesion.

To solve those problems, the project that I’d worked for the last 8 months (Onibus Recife) used a combination of 3 technologies, and this post is about them.

NHibernate

NHibernate is an Object-relational mapping (ORM) solution for the Microsoft .NET platform: it provides a framework for mapping an object-oriented domain model to a traditional relational database. NHibernate’s primary feature is mapping from .NET classes to database tables. NHibernate generates the SQL commands and relieves the developer from manual data set handling and object conversion, keeping the application portable to most SQL databases, with database portability delivered at very little performance overhead.

NHibernate was used exactly for this purpose: create SQL commands and provide database portability.

Generics

Generics is a programming feature added in the .NET Framework 2.0 which allow you to define type-safe data structures, without committing to actual data types. This results in a significant performance boost and higher quality code, because you get to reuse data processing algorithms without duplicating type-specific code.

Using Generics, our team was able to use one, and just one, repository class for all of the simple persistent entities. Every time a new entity was add to the project, nothing more than its corresponding .hbm file was needed.

Autofac

Autofac is a fresh approach to IoC in .NET that fits well with C# 3.0.

The Autofac framework enabled us to inject all classes’ dependencies in just one place. So, when dependences changed, just a few lines of code were modified in a single source code file.

To illustrate those techniques, I’ll use them in a sample and small project.
Imagine a simple Contacts project used to keep your friends’ address, phone number and birthday. The abstraction of a contact is shown below.

Contact.cs

In order to persist the Contact class in my SQL Server database, I used NHibernate framework. Due to that, I need an .hbm file for the Contact class and a NHibernate session manager, responsible to manage database access. Because it’s a small and very simple project, I created a simple session manager, shown below.

NHibernateSessionManager.cs

Now, it’s time for the repository class. Actually, I implemented a repository interface and its implementation. Remember: program for abstractions, not for implementations. Note that they are generic. I did this to provide a single persistent implementation for more than one entity and simplify my life as a programmer. The code of them is listed below.

IRepository.cs

NHibernateRepository.cs

Now, let’s test our code reading data from the database. For that, I used the following piece of code.

TestReadContactById

The test passed, so everything is working.

Now imagine that we need another entity class, for example, a User, to restrict the program access with a username and password. All that I have to do is creating the User.cs abstraction and the User.hbm.xml file. I don’t need a new CRUD class for it. I just use the same generic repository that I used for Contact class, saving me a lot of time. Below is the code that I used to retrieve a user from the database.

TestReadUserById

Note that we must instantiate a new NHibernateRepository with a NHibernateSessionManager as parameter every time we need a new IRepository instance. Probably, in a big project, this line of code will be scattered in a huge number of files and, if that instantiation change for any reason, a lot of files will be modified. That’s what we don’t want. We like when changes are made in just one place and that is the work of Autofac framework.

Take a look of how the same tests are made using Autofac.

AutofacRepositoryTest.cs

The framework will inject all classes’ dependencies in the beginning of the program execution. Later, to instantiate an object, we ask the framework to resolve its type. If its instantiation changed, just the line of code where Autofac register is changed.

Conclusion

In this post, I’ve introduced a combination of NHibernate, Generics and Autofac. With these technologies in hand, I was able to create an extensible persistent layer in a low coupling and high cohesion way as shown in the sample project created.

For more information about this technologies see Hibernate and Autofac documentation.

See you.

–
Fernando