2010-11-03 45 views
8

Estaba leyendo algunas publicaciones y noté muestras con una clase interna. Lo he estado viendo mucho últimamente, particularmente en algunos ejemplos en MSDN que estaba revisando. Nunca antes tuve que usar una clase interna (pero tal vez debería serlo), así que me pregunto cuál es exactamente el punto. Supongo que una clase interna (al menos una privada) está solo disponible para la clase principal en sí misma, entonces ¿no sería lo mismo simplemente incorporar cualquier funcionalidad que la clase interna tenga en algunos métodos de la clase externa? ¿Hay una razón OO detrás de la clase interna?¿Propósito de una clase interna?

Estoy pensando principalmente en C#, pero supongo que esto podría aplicarse a cualquier lenguaje OO que admita una clase interna.

Tome this sample on msdn por ejemplo: CharacterCollection y WordCollection son clases públicas dentro de la clase Document. ¿Qué diferencia habría si estos estuvieran fuera de la clase Document?

Respuesta

6

Las clases internas son muy útiles si solo pertenecen a su clase contenedora (o externa).

Un buen ejemplo de una clase privada interna es cuando necesita administrar algo dentro de la clase externa que nunca estará expuesto. En el siguiente ejemplo, un administrador de caché maneja el almacenamiento en caché y el almacenamiento en caché de objetos. Utiliza una clase interna privada para almacenar el puntero a un objeto que quiere almacenar en caché, y también la hora a la que se accedió por última vez. Código que los usuarios de este hipotético CacheManager nunca necesitan saber sobre CacheEntry.

class CacheManager 
{ 
private: 
    class CacheEntry 
    { 
    private: 
     Object* m_pObjectToCache; 
     int  m_nTicksSinceTouched; 
    }; // eo class CacheEntry 
    std::map<int, CacheEntry*> m_Cache; 

public: 
    Object* getObject(int _id); 
}; // eo class CacheManager 

Luego viene el caso de una clase interna pública. Me gustaría utilizar una clase anidada si el nombre (que me gustaría mantener sencilla), mi conflicto en otra parte:

class Tree 
{ 
public: 
    // public class.. Node might pertain to anything in the code, let's keep it simple 
    // and clear that THIS Node belongs and works with THIS Tree class. 
    class Node 
    { 
    };// eo class Node 
}; // eo class Tree 
+0

Entonces, en este ejemplo, ¿cómo usarías Node? Cuando pienso que es público, imagino que de alguna manera tengo acceso a él fuera de Tree, ¿sería ese el caso o el hecho de que Node sea público de alguna manera hace que anule otra clase Node que se encuentra fuera de Tree? – pinkfloydx33

+0

Sí, porque está fuera del árbol, es accesible como "Árbol :: Nodo", lo que garantiza que obtendrá el Nodo que desea. También está claro para cualquier otro lector del código a qué nodo se refiere. –

+0

Dentro de Tree entonces supongo que no tendría que especificar que quería Tree :: Node versus SomeOtherNS :: Node? – pinkfloydx33

3

Una de las razones es que las clases internas tienen acceso a los miembros de la clase adjunta directamente. No necesitan una referencia a la clase adjunta para acceder a esos miembros. Al mismo tiempo, otros objetos pueden necesitar acceso al objeto interno.

Puedo pensar en el ejemplo de Iteradores que están declarados como clases internas en colecciones. El iterador necesita tener un conocimiento íntimo de la colección que itera, pero el código del cliente necesita acceso al iterador mismo como un objeto. No puede tomar la funcionalidad del iterador e incluirlo en la clase externa.

Tal vez las responsabilidades de la clase externa no incluyen las de la clase interna directamente. Entonces, crear la clase interna ayuda a mantener clases altamente cohesivas.

+0

Personalmente estoy en contra de las clases internas - Yo prefiero votar por algo como palabra clave "amigo" de C++. –