oop - público - protected php
Práctica recomendada: ordenamiento de público/protegido/privado dentro de la definición de clase. (10)
Estoy comenzando un nuevo proyecto desde cero y quiero que esté limpio / tenga buenos estándares de codificación. ¿En qué orden les gusta a los desarrolladores experimentados aquí presentar las cosas dentro de una clase?
A: 1) métodos públicos 2) métodos privados 3) vars públicos 4) vars privados
B: 1) vars públicos 2) vars privados 3) métodos públicos 4) métodos privados
C: 1) vars públicos 2) métodos públicos 3) métodos privados 4) vars privados
En general, me gusta poner vars públicos estáticos en la parte superior, pero entonces, ¿un método público estático se enumerará antes que tu constructor, o el constructor siempre debe aparecer primero? Esa clase de cosas...
Sé que es difícil pero me pregunto: ¿cuáles son las mejores prácticas para esto?
PD: no, yo no uso Cc #. Lo sé. Soy un luddite.
Algunos editores, como Eclipse y sus descendientes, le permiten reordenar en la vista de esquema los vars y los métodos, alfabéticamente o como en la página.
Creo que tengo una filosofía diferente sobre esto que la mayoría. Prefiero agrupar elementos relacionados entre sí. No soporto tener que saltar para trabajar con una clase. El código debería fluir y usar un orden más bien artificial basado en la accesibilidad (pública, privada, protegida, etc.) o instancia frente a estática o miembro versus propiedad versus función no ayuda a mantener un buen flujo. Entonces, si tengo un Method método público implementado por los métodos de ayuda privada HelperMethodA , HelperMethodA , etc. en lugar de tener estos métodos muy separados el uno del otro, los mantendré cerca el uno del otro. Del mismo modo, si tengo un método de instancia que se implementa mediante un método estático, los agruparé también.
Entonces mis clases a menudo se ven así:
class MyClass {
public string Method(int a) {
return HelperMethodA(a) + HelperMethodB(this.SomeStringMember);
}
string HelperMethodA(int a) { // returns some string }
string HelperMethodB(string s) { // returns some string }
public bool Equals(MyClass other) { return MyClass.Equals(this, other); }
public static bool Equals(MyClass left, MyClass right) { // return some bool }
public double SomeCalculation(double x, double y) {
if(x < 0) throw new ArgumentOutOfRangeException("x");
return DoSomeCalculation(x, y);
}
const double aConstant;
const double anotherConstant;
double DoSomeCalculation(double x, double y) {
return Math.Pow(aConstant, x) * Math.Sin(y)
+ this.SomeDoubleMember * anotherConstant;
}
}
En Clean Code , Robert C. Martin aconseja a los codificadores que siempre coloquen las variables miembro en la parte superior de la clase (primero las constantes, luego los miembros privados) y los métodos deben ordenarse de tal manera que se interpreten como una historia que no causa el lector necesita saltar demasiado el código. Esta es una forma más sensata de organizar el código en lugar de hacerlo mediante el modificador de acceso.
En general, estoy de acuerdo con el orden público, protegido y privado, así como con los datos estáticos, los datos de los miembros y el orden de las funciones de los miembros.
Aunque a veces me agrupo como miembros (getters & setters) generalmente prefiero enumerar miembros dentro de un grupo ALPHABETICALLY para que puedan ubicarse más fácilmente.
También me gusta alinear los datos / funciones verticalmente. Hago tab / espacio lo suficiente para que todos los nombres estén alineados en la misma columna.
Este sería mi pedido
- Variables estáticas
- Métodos estáticos
- Variables públicas
- Variables protegidas
- Variables privadas
- Constructores
- Métodos públicos
- Métodos protegidos
- Métodos privados
Yo uso las siguientes reglas:
- estático antes que nada
- variables antes de los constructores antes que los métodos (considero que los constructores están en la categoría de métodos)
- público antes protegido antes privado
La idea es que definas el objeto (los datos), antes de los comportamientos (métodos). Las estadísticas deben separarse porque no son realmente parte del objeto, ni su comportamiento.
La mejor práctica es ser consistente .
Personalmente, prefiero poner primero los métodos public , seguidos por protected métodos protected , siguiendo por métodos private . En general, los datos de los miembros deben ser siempre privados o protegidos, a menos que tenga una buena razón para que no sea así.
Mi razonamiento para poner public métodos public en la parte superior es que define la interfaz para su clase, por lo que cualquier persona que lea detenidamente su archivo de encabezado debería poder ver esta información de inmediato.
En general, private miembros private y protected son menos importantes para la mayoría de las personas que miran el archivo de encabezado, a menos que estén considerando modificar las partes internas de la clase. Mantenerlos "fuera del camino" garantiza que esta información se mantenga solo en función de la necesidad de conocerla , uno de los aspectos más importantes de la encapsulación.
La secuencia de público seguida por protegida y privada es más legible para mí. Es mejor describir la lógica de clase en los comentarios en la parte superior del archivo de encabezado simplemente y llamar órdenes de función para comprender qué clase de dosis y qué algoritmos se usan en el interior.
Estoy usando Qt c ++ por un tiempo y veo un nuevo tipo de palabras clave como signal y slot . Prefiero seguir ordenando como arriba y compartir mi idea contigo aquí.
#ifndef TEMPLATE_H
#define TEMPLATE_H
class ClassName
{
Q_OBJECT
Q_PROPERTY(qreal startValue READ startValue WRITE setStartValue)
Q_ENUMS(MyEnum)
public:
enum MyEnum {
Hello = 0x0,
World = 0x1
};
// constructors
explicit ClassName(QObject *parent = Q_NULLPTR);
~ClassName();
// getter and setters of member variables
// public functions (normal & virtual) -> orderby logic
public slots:
signals:
protected:
// protected functions it''s rule followed like public functions
private slots:
private:
// methods
// members
};
#endif // TEMPLATE_H
Para cada uno, y como dice Elzo, los IDEs modernos han hecho que sea más fácil encontrar miembros y sus modificadores de una manera fácil con iconos de colores en menús desplegables y cosas así.
Mi opinión es que es más importante para el programador saber para qué se diseñó la clase y cómo se puede esperar que se comporte.
Entonces, si es un Singleton, coloco primero la semántica (clase estática getInstance ()).
Si se trata de una fábrica de concreto, pongo primero la función getNew () y las funciones de registro / inicialización.
... y así. Cuando digo primero, me refiero pronto después de los c''tors y d''tor, ya que son la forma predeterminada de instanciar cualquier clase.
Las funciones que siguen están entonces en:
- orden de llamada lógica (por ejemplo, initialize (), preProcess (), process (), postProcess ()), o
- funciones relacionadas en conjunto (como accesos, utilidades, manipuladores, etc.),
dependiendo de si la clase estaba destinada principalmente a ser un data-store con algunas funciones, o un proveedor de funciones con unos pocos miembros de datos.
Personalmente me gusta tener público en la parte superior, protegido y luego privado. La razón de esto es que cuando alguien abre el encabezado, ve a qué puede acceder primero, luego más detalles a medida que se desplaza hacia abajo.
Yo solía importarme mucho En los últimos años, usando IDEs modernos, casi todo está a solo 1 o 2 teclas de distancia, he dejado que mis estándares se relajen sustancialmente. Ahora, empiezo con estática, variables miembro, luego constructores, después de eso no me preocupo demasiado.
En C # dejo que Resharper organice las cosas automáticamente.