The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
|
Just as it is a good practice to make all fields private unless they need greater visibility, it is a good practice to make all fields final unless they need to be mutable.
–Brian Goetz
in Java Concurrency in Practice (page 48) |
Are you following these fundamental principles?
Just so we’re on the same page, an immutable object is on whose state cannot be changed after construction.
This view is supported by Joshua Bloch in Effective Java (2nd). Item 13 states: “Minimize the accessibility of classes and members.”
|
|
The single most important factor that distinguishes a well-designed module from a poorly designed one is the degree to which the module hides its internal data and other implementation details from other modules.
–Joshua Bloch
|
He goes on to say some fundamental principles.
|
|
A well designed module hides all of its implementation details, cleanly separating its API from its implementation. Modules then communicate only through their APIs and are oblivious to each others’ inner workings.
–Joshua Bloch
Effective Java (2nd), page 67 |
These are really the basics of information hiding or encapsulation. Basics of OOP programming! It’s a good idea to learn these well.
Think twice before making any fields public. Hold it. No, don’t make it public! Think twice before making it any other than private!
But to make sure you only expose what is absolutely needed requires some thought. You need your own judgment and experience.
As for the second part, item 15 states: “Minimize mutability.”
I think this one is a little harder to justify and not so obvious. But Bloch has some very good arguments. Together with Goetz, they convinced me that I should utilize immutability more often when I’m designing classes.
|
|
Immutable classes are easier to design, implement, and use than mutable classes. They are less prone to error and are more secure.
–Joshua Bloch
|
Convinced!
But how? Follow these 5 steps (as per Bloch).
1. Don’t provide any methods that modify the object’s state.
2. Ensure the class can’t be extended.
3. Make all fields final.
4. Make all fields private.
5. Ensure exclusive access to any mutable components.
Goets says it a little bit differently.
An object is immutable if:
– Its state cannot be modified after construction;
– All its fields are final;
– It is properly constructed (the this reference does not escape during construction)
Immutable objects pack a lot of goodies in them.
One more time. Tell me what are the benefits of immutable objects!
They are simple to understand.
They are thread safe.
They require no synchronization.
Let’s end with a great summary note from Bloch, “Classes should be immutable unless there’s a very good reason to make t hem mutable.”
But.
If…
“If a class cannot be made immutable, limit its mutablity as much as possible.”
Strong statements.
Learn these design principles!
All in all, I recommend reading Item 15 from the Effective Java book. And re-read a few times until it becomes part of your design logic.
It’s all about getting better.
It’s all about improving.
It’s good to learn from the pros. Everybody needs a little guidance. I know I do. (These 2 books are excellent! Recommended.)
I must admit. I am still having hard time seeing a real difference. I am still having hard time defining them both.One thing I am sure: both are fundamental principles of object oriented programming. I am going to try to learn them here and explain the differences. Just so I know for future.
“Abstraction and encapsulation are not synomous,” says P.J. Plauger in Programming on Purpose.
Encapsulation is information hiding. I think that’s the best way to define it and remember it. “Information hiding allows for implementation of a feature to change without affecting other parts that are depending on it.”
P.J. Plauger has a great analogy and definition of information hiding.”Information hiding is not the same as secrecy. The idea is not to prevent outsiders from knowing what you are doing inside a module. Rather, it is to encourage them not to depend on that knowledge. That leads to a kind of secondary coupling which is more pernicious than obvios dependency because it is less visible. You should encapsulate information to keep it private, not secret. (What you do in the bathroom is no secret, but it is private.)”
“Stuff all of the code that is likely to change in a module [class] and hide its innards.” That not only defines information hiding, but it is also a fundamental principle developing: when to create a new class, when to refactor.
Abstraction. Look at it as “what” the method or a module does not “how” it does it. I just found a great definition of abstraction: “The notion abstraction is to distill a complicated system down to its most fundamental parts and describe these parts in a simple, precise language.”
Let’s compare Java and C++. We have a good example of abstraction. In C++, you have to deal with pointers and references a lot. You have to deal a lot of garbage collection. In essence, you have to work on a low level. (C and C++ in turn abstracted a lot of even lower level machine code.) In Java, those things are abstracted away. You just assume they exist. In essence, abstraction means that you are working on a higher level. You don’t care how pointers work in Java, you just assume that they work. You don’t have to concentrate on the lower level stuff, you work on higher level.
I think abstraction is extremely important. By working more abstractly we can solve more and more difficult problems because we don’t have to concentrate on the lower level details. As Steve McConnel puts it, we are working closer to the business domain.
So to summarize, I think I got it now. Encapsulation is information hiding. Abstraction means working on a higher level, not worrying about the internal details. They go hand in hand. The bottom line, even if you still don’t know the differences, utilize information hiding; make your programs more abstract by creating classes with responsibility and then talk about the feature by the name of the class, but what it does, not by how it is doing it (that’s abstraction, I think).
