visualbasic net namespace microsoft invalid computer code asp .net namespaces nested nested-class

.net - net - Tipos anidados que son públicos



namespace my c# (4)

Tengo curiosidad sobre qué es una buena práctica cuando se trata de ciertos escenarios que involucran tipos anidados en .NET.

Digamos que tienes una clase Wheel, y la clase Wheel contiene objetos Bearing. Un objeto Teniendo solo tiene sentido dentro de una Rueda y no desea permitir que se cree de forma independiente, por lo que tendría sentido tener la clase Teniendo anidada dentro del objeto Rueda. Sin embargo, supongamos que tiene un escenario donde ahora necesita leer una propiedad Wheel.Bearings fuera de la clase Wheel. Esto ahora requeriría hacer pública la clase Bearing anidada.

En esta situación, ¿cuál es la mejor opción?
1 - Crea una clase pública de Rumbo anidada dentro de la clase Wheel
2 - Crea una clase Bearing independiente que toma un objeto Wheel en su constructor
3 - Crea un espacio de nombres Wheel y crea una clase Bearing independiente dentro de este espacio de nombres.
4 - ¿Algo más?

ACTUALIZACIÓN: estoy actualizando esto con más detalles y para reflejar algunas de las sugerencias hasta el momento. ClassParent es la clase principal, ClassChild es la clase infantil. ClassChild es SIEMPRE un hijo de ClassParent, no tiene sentido existir por sí mismo. El problema es que ClassChild tiene algunas propiedades que deben exponerse públicamente, mientras que el resto solo debe invocarse desde ClassParent. Un ejemplo es una función ClassChild.Delete que no debe exponerse públicamente porque solo debe invocarse desde ClassParent ya que ClassParent necesita realizar la limpieza y las modificaciones apropiadas.

Después de revisar las sugerencias, el diseño que he ideado me parece un poco sucio, así que pensé en pedirle su opinión. Yo tengo:

public class Parent { ChildNested childObj public DeleteChild() { //expose this method publically childObj.DeleteChild() //other functionality } public Child GetChild() { //expose Child, not ChildNested publically return childObj } private class ChildNested:Child { public Child() { Base.Child() } public DeleteChild() { Base.Delete() } } public abstract class Child { protected Child() { } protected Delete() { } public PublicPropertyToExpose() { } }


El mejor diseño aquí es crear una clase de Bearing público con un constructor internal y crear instancias de él dentro de la clase Wheel .

Si la clase Bearing necesita acceder a miembros privados de la clase Wheel , puede hacer que la clase pública Bearing abstract , luego hacer una implementación concreta como una clase private anidada dentro de Wheel .

En general, no debe hacer tipos anidados public .


Me gustaría probar "Teniendo" de forma independiente, así que iría por la segunda opción.


Un rodamiento puede existir por sí mismo, porque probablemente sea lo suficientemente útil como para ser utilizado en cualquier parte del mundo, fuera de una rueda.

Una rueda se agrega utilizando rodamientos, pero una rueda no define un rumbo. Los rodamientos son útiles y pueden usarse en otras cosas además de las ruedas.

El hecho de que necesite una propiedad pública para Bearing indica que debe ser una clase pública, fuera de Wheel.

Además, ¿qué sucede cuando reinventa la Rueda (todos lo hacemos ...). Tal vez use un nuevo "cojinete de aire", como el que existe en las microturbinas, ahora tiene múltiples tipos de cojinetes dentro de la clase Wheel, algunos de los cuales no se utilizan.

Colocaría el rodamiento dentro del mismo espacio de nombres, pero no dentro de la clase Wheel. Rara vez encuentro la necesidad de clases internas. Por lo general, una clase anónima rellena los vacíos que necesito.


  • Crear una clase Bearing independiente con constructor privado
  • Crear una clase de fábrica que creará una instancia de la clase Teniendo dada una clase de Rueda