tagged by: encapsulation
Object-oriented languages divide a program into modules called classes. Each class contains features, which consist of data (fields) and methods. (Not all languages use these terms, but they'll do for this.) Languages have various rules about what other classes can access the features of a class, these are often based on access modifiers that apply to a class.
13 May 2003
If you learn about object-oriented design, you quickly learn that it's important to encapsulate your data. The simplest form of encapsulation is to use accessors (getting and setting methods) or properties - if your language supports it. (Some even do this within the class - SelfEncapsulation
It's very useful to separate methods into those that change state and those that don't. Non-state changing methods (which I call queries), can be used in any context without worrying about how they sequence with other methods.
OO designers differ about whether you should make all your data private or whether they allow some to be public.
14 May 2003
Published Interface is a term I used (first in Refactoring) to refer to a class interface that's used outside the code base that it's defined in. As such it means more than public in Java and indeed even more than a non-internal public in C#. In my column for IEEE Software I argued that the distinction between published and public is actually more important than that between public and private.
26 December 2003
Self Encapsulation is designing your classes so that all access to data, even from within the same class, goes through accessor methods.
One of the longest running arguments on object-oriented circles is the debate between OpenInheritance and Designed Inheritance. The principle of Designed Inheritance is probably best summed up by Josh Bloch: "Design and document for inheritance or else prohibit it". With this approach you take care to decide which methods can be inherited and Seal the others to stop them being overridden.
6 October 2006
You can tell them by the twitch in the left hand side of the mouth when they see a getter method, there's swift pull on their battleaxe and a satisfied cry as another getter is hewn unmercifully from a class which immediately swoons in an ecstasy of gratefulness at the manly Getter Eradicator's feet.
22 February 2006
This is the opposite attitude to DesignedInheritance. Advocates of open inheritance do not look to disallow inheritance by Sealing their classes or doing anything else to stop people inheriting classes.
When I first came across C# I liked the notion of properties
right from the start. The getX and setX conventions of C++/Java always
seems rather silly to me, it's much more natural to write
= other.X. Providing a property with get and set methods turns
a common convention into a naturally supported feature of the
4 February 2004
Sealing a method or a class prevents subclasses from overriding it.
All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.
-- Bertrand Meyer
Bertrand Meyer coined this principle in his highly-influential book Object-Oriented Software Construction.
The essential point of the principle is that if you have a person object and you ask it for its age, you should use the same notation whether the age is a stored field of the object or a computed value. It effectively means that a client of the person should neither know nor care whether the age is stored or computed.
20 April 2011