I have an n tier application with presentation layer, business layer, DAL and business objects layer. Separating the objects and the operation written on the objects break the object oriented concept of encapsulation.
4 Answers
2
votes
No. Consider what "encapsulation" means: the implementation details of a class are concealed behind the interface (messages, or methods) of the class.
In fact, you can derive the n-tier architecture directly from OO principles and Parnas's Law: a module should encapsulate what's likely to change. The presentation tier encapsulates the details of creating a "visible" interface; the middle tier the model of the business itself; and the back end the details of accessing the persistent data store.
1
votes
Take this example, taken from this article:
public class Position
{
public double distance( Position position )
{
// calculate and return distance...
}
public double heading( Position position )
{
// calculate and return heading...
}
public double latitude;
public double longitude;
}
According to the same article this is a good example of encapsulation, because data and operations that perform on that data are bundled. Note that encapsulation here does not guarantee data hiding or protection.
In contrast, Steve McConnell in Code Complete (2nd. ed., Section 6.2, Good Encapsulation) would argue that encapsulation is broken, because member data is exposed.
In your situation, if your data objects and the objects manipulating them are separated but don't have public fields, then encapsulation is broken according to the first definition, but not necessarily in the second case. So we have two contrasting views. One says data hiding is not a part of encapsulation, the other source says data hiding is a vital part of encapsulation.
Data hiding can be seen as a part of information hiding which is the principle that states you should hide complex design decisions and sources of change. The general consensus seems to be that encapsulation is seen as a manifestation of information hiding, including data hiding.
Or, as Wikipedia puts it:
The term encapsulation is often used interchangeably with information hiding. Not all agree on the distinctions between the two though; one may think of information hiding as being the principle and encapsulation being the technique. A software module hides information by encapsulating the information into a module or other construct which presents an interface.
But... the reference that follows this paragraph is the same article from which I took the first example, so even Wikipedia is mixing up things here. Also, the use of the word "distinctions" seems wrong here.
It's a bit lame to have to say this at the end, but the terminology for encapsulation and information hiding is overloaded, so it all depends on the source. In your case I would stick to the definition of encapsulation as "hiding implementation details behind an abstraction". Therefore you are not necessarily breaking encapsulation.
0
votes
That's a really great point AP!
In some cases, I would agree that breaking a single operation into multiple objects does indeed adversely affect encapsulation. In fact, I think this is a big problem I've seen in many web architectures.
On the other hand, certain things are useful to decompose, such as as an object to send queries to the database, etc.
I think there is an argument to be made, in many instances, to better "encapsulate" a web page, so that more of the functionality is contained with a single object or less objects. Thus, a more "page-centric" approach, rather than scattering the logic across vast multitudes of classes.
I think this is a vital question we always have to ask ourselves with each system we design--how much to abstract? How much to keep specific? How to effectively decompose the system into classes.
-1
votes
The two are not the same. An architecture is more referring to modules (groups of classes). Encapsulation refers to hiding the inner workings of a class. You can have both if you design your system well enough.
What you might need to be careful about is in clearly defining the separation of responsibility. As long as you are clear about what each module/layer is for, and specific about what each class does (and what each method of the class does), then you should be able to have a good design.
I'm just speculating here, but you may be interested in the facade design pattern when designing an interface to a module.
With respect to your comment below, the logic should definitely be in the employee class itself. I would question the logic in having a separate layer for business objects. It is often a temptation to define classes like "Employee" because they model real-world objects or concepts. However, your motivation for defining a class should not be "modelling a real-world object".
You should define the purpose of your module (why do you have a business logic layer? To contain all the business logic.) and then put what you need in there. If the "Employee" class is the class that needs to calculate business logic, then it should go in the business logic class. If not, then it should go in your business objects class (whatever that's for). If it needs to do two different things, and thus could fit in two layers, then consider separating it into two classes - remember that your objects don't need to model real-world things. Robert C Martin suggests defining your classes such that the boundaries of the classes are the boundaries of purpose.
