What is the antonym of encapsulation?

Using online dictionary tools doesn't really help. I think the way encapsulate is use in computer science doesn't exactly match its meaning in plain English.

What is the antonym of computer science's version of encaspulate? More specifically, what is an antonym for encapsulate that would work as a function name.

---

Why should I care? Here's my motivation:

// A class with a private member variable;
class Private
{
public:
   // Test will be able to access Private's private members;
   class Test;
private:
   int i;
}

// Make Test exactly like Private
class开发者_开发问答 Private::Test : public Private
{
public:
   // Make Private's copy of i available publicly in Test
   using Private::i;
};

// A convenience function to quickly break encapsulation on a class to be tested.
// I don't have good name for what it does
Private::Test& foo( Private& p )
{ return *reinterpret_cast<Private::Test*>(&p); } // power cast

void unit_test()
{
   Private p;
   // using the function quickly grab access to p's internals.
   // obviously it would be evil to use this anywhere except in unit tests.
   assert( foo(p).i == 42 );
}

---

The antonym is "C".

Ok, just kidding. (Sort of.)

The best terms I can come up with are "expose" and "violate".

---

The purpose behind encapsulation is to hide/cover/protect. The antonym would be reveal/expose/make public.

---

How about Decapsulation..

Though it aint a computer science term, but in medical science, Surgical removal of a capsule or enveloping membrane.. Check out here..

---

"Removing/Breaking encapsulation" is about the closest thing I've seen, honestly.

If you think of the word in the English sense, to encapsulate means to enclose within something. But in the CS sense, there's this concept of protection levels and it looks like you want to imply circumventing the access levels as well, so something like "extraction" doesn't really convey the meaning you're looking for.

But if you just think of it in terms of what the access levels are, it looks like you're making something public so, how about "publicizing"?

---

This is not such a simple question - Scott Meyers had an interesting article to demonstrate some of the nuances around encapsulation here.

I'll start with the punchline: If you're writing a function that can be implemented as either a member or as a non-friend non-member, you should prefer to implement it as a non-member function. That decision increases class encapsulation. When you think encapsulation, you should think non-member functions.

---

How about "Bad Idea"?

---

The true antonym of "Encapsulation" is "Global State".

---

The general opposite of encapsulation is coupling and we often talk about systems that are tightly coupled or loosely coupled.

The reason you'd want components to be encapsulated is because it makes it easier to reason about how they work.

Take the analogy of trains: the consequence of coupling the railcars is that the driver must consider the characteristics (inertia, length) of the entire train.

Obviously, though, we couple systems because we need them to work together.

Inverted encapsulation and data structures

There's another term that I've been digging for, which is how I came across this question, that refers to a non-standard style of data structures.

The standard style of encapsulation is exemplified by Java's LinkedList; the actual nodes of the list are designed to be inaccessible to the consumer. The theory is that this is an implementation detail and can change to improve performance, while existing code will continue to run.

Another style is the classic functional cons-list. This is a singly linked list, and the idea is that it's so simple that there's nothing to improve about the data structure, e.g.

data  [a]  =  [] | a : [a]  deriving (Eq, Ord)

-- Haskellers then work directly with the list
-- There's nothing to hide because it's so simple
typicalHaskell :: [a] -> b
typicalHaskell [] = emptyValue
typicalHaskell h : t = h `doAThing` (typicalHaskell t)

That's the definition from Haskell's standard prelude though the report notes that isn't valid Haskell syntax, and in practice [a] is defined in the guts of the compiler.

Then there's what I'm calling an "inverted" data structure, but I'm still looking for the correct term. This is, I think, really the opposite of encapsulation.

A good example of this is Python's heapq module. The data structure here is a binary heap, but there isn't a Heap class. Rather, you get a collection of functions that operate on generic Python lists and you're responsible for using those methods correctly to ensure the heap invariants are maintained.

---

How about "spaghetti"?