Perdido en C++

#62 ah, que este hilo va de C++? Creí que estábamos en el de estilo de código xD

#57 Depende, cuando programo en Lisp o Perl por poner un ejemplo rara vez suelo poner algún comentario ya que son lenguajes muy expresivos y generalmente con un simple stringdoc sobra.

Pero cuando lo que escribes es algo como esto:

qks:{f:*x@1?#x;:[0=#x;x;,/(f x@&x<f;x@&x=f;f x@&x>f)]}

Lógicamente entenderás el que se le preste algo más de dedicación al tener una documentación en condiciones (que en este caso no hace falta porque todo el mundo sabe hacer un quicksort, pero en un entorno real de producción rara vez se suelen ver estos hola-mundos).

De todas formas ten en cuenta que lo que tú consideres como legible o self-documented es altamente subjetivo. Y ahí radica el problema de lo que expones.

#64 Pues yo uso GOTOs para simular TCO en Perl modificando el stack implícito y al que no le guste que no mire xD

#68 Usar accessors en POO es una putísima mierda y esto también es objetivo

https://github.com/SantiMunin/Nomasystems-exercise/blob/master/src/es/udc/santiago/data/entities/Company.java

#69 discreparía contigo si no fuera porque el 90% de las veces son innecesarios

Anda que no he visto veces hacer una clase Point con accesores para la "x" y la "y" (típico bean.)

FUCK THE POLICE.

#70 accedentes y mutadores? Suena a panch xD

#70 cogedores y ponedores, de toda la vida xD

#72 Usar un accesor es tan feo como poner las variables miembros como públicas y acceder a ellas directamente.

Negativo. Lo de usar accesores públicos es para, si en algún momento cambia la implementación interna del objeto, no tener que cambiar también su interfaz (y por tanto romper todo el resto del programa que accedía a los miembros públicos.)

E.g.: ¿qué pasa si en algún momento un miembro de tu objeto deja de existir como tal para pasar a ser un valor calculado? Si tienes el setter/getter puedes cambiar su implementación, no rompes la API, el miembro ya no existe y todo el mundo está contento.

Como un ejemplo rápido: imagina que tienes Persona (¡qué ejemplo más original!) con el campo "int edad" recubierto por un accesor (sin setter.) En algún momento decides dejar de guardar la edad para tener fecha de nacimiento (y calcular la edad con esta.) Si tienes el getter hecho haces que calcule la edad y SANTAS PASCUAS. Sin accesor, al borrar el campo edad romperías todo el código que lo usara como API.

me referia a un accesor público, eso rompe la encapsulación de objetos.
No. No lo hace. Si tienes un setter público es porque necesitas acceder al miembro del objeto de alguna forma. ¿La diferencia? El setter no te permite modificar el valor directamente. Es decir, no te permite "bypassear" el mecanismo impuesto por el objeto.

Con el getter, tres cuartas de lo mismo. Un getter público permite hacer una copia de guarda de los objetos mutables. El acceso público al miembro no.

Por esta razón no se rompe la encapsulación aunque tengas acceso a los miembros internos. Estos quedan encapsulados por sus settergetter.

Deberia existir un método público que no haga referencia a ellos mismos del tipo getData(blablabla),setData(blablabla).
No sé si te he entendido bien. Los objetos tienen miembros de salida, si no tendríamos objetos que sólo interactúan por métodos pero son completamente ciegos a los datos de otros objetos (y si no son ciegos es porque has hecho un accesor, aunque sea más complejo que un simple return... sigue siendo un accesor.)

#74 75 El uso de accesors significa una mal diseño.

un ejemplo de objeto bien encapsulado:

#include <iostream>
using namespace std;

class CRectangle {
    int x, y;
  public:
    void set_values (int,int);
    int area () {return (x*y);}
};

void CRectangle::set_values (int a, int b) {
  x = a;
  y = b;
}

int main () {
  CRectangle rect;
  rect.set_values (3,4);
  cout << "area: " << rect.area();
  return 0;
}

Si en vez de set_values usaramos accessors tendriamos dos problemas:

1) tendriamos un accesor por variable = más código a mantener
2) Estamos exponiendo públicamente las variables miembro y va en contra directamente de lso principios de encapsulación.

#77 de hecho no tiene por qué estar bien lo que has hecho.

Para empezar ese set lo haria en la contructora. Y si quiero cambiar solo la X o (or exclusiva) la Y y no conozco previamente ninguna?

No tienes por qué tener un accesor por variable, sino uno por propiedad que te interese querer cambiar.

No expones publicamente ningún atributo, porque precisamente alguien que solo tiene acceso a la interfaz (API) no tiene ni repajolera de si a lo que accede es a un atributo o es a una formula que los usa.

Estás muy equivocada en concepto, y tratas de generalizar la función de los atributos cuando no son "simples variables" todos.

#78 lo del set lo dejé a propósito para indicar que aunque tuviera un set no es un setter. Podrñia ser un constructor como bien dice #79 y no seria un setter. El nombre del método para mi no indica si es un accesor o no. Otra cosa es que por convencionalismo se use o no.

Ahora haz lo mismo con esta clase, es decir, escríbela sin usar accesores. Con un pequeño detalle: la API necesita acceder a los miembros por separado.

Cual es la razón de que la api necesite acceder a un solo campo de los datos de una persona?.

#81 lo del set lo dejé a propósito para indicar que aunque tuviera un set no es un setter.
Pero es que ES un setter.

Podrría ser un constructor como bien dice #79 y no seria un setter.
Y si mi abuela tuviera ruedas sería un bicicleta. Claro que si lo pones en el constructor no es un setter xD

Cual es la razón de que la api necesite acceder a un solo campo de los datos de una persona?.

Era un ejercicio mental pero bueno, si quieres me lo invento: para sacar estadísticas del nombre más común en un país, por ejemplo.

No vale concatenar y des-concatenar luego, imagina nombres como "Felipe Juan Froilán de Todos los Santos de Marichalar de Borbón". Necesito el nombre y apellidos por separado.

#84

¿y que valor me devolvería ese método getSize()? Pon un ejemplo con churricódigo igual que he hecho yo.

#85

juaaaaaas, creo que estás llevando está discusión al absurdo... vamos que según tú devolver un array con los valores x e y, es un diseño correcto, mientras que devolver por separado los valores x e y es una aberración, además que tu getSize() por el hecho de devolver los dos valores a la vez, ya deja de ser un accesor????

Según tu ejemplo al final tendría que hacer esto:

anchoObjeto = sprite.getSize()[0] / RATIO_PIXELS_METROS
altoObjeto = sprite.getSize()[1] / RATIO_PIXELS_METROS

Que viene a ser exactamente lo mismo.

#88 ???? entonces cual es el sentido que tu le das? porque debes ser única XD

y desde luego devolver un array en ese caso es caca de la vaca xD