Is this bad OOP design?

Is it bad OOP design to have purely data objects? ie objects whos only purpose is to carry around data? (For example a user object who only has a username field, but has a usermanager class taking care of user-related stuff.)

the entire idea is to represent a concept and the operations that affect the concept by encapsulating state and class.
yes.

>>1
Sounds like pretty good CLOS design. By Smalltalk standards it would be stupid, but it turns out that inverting your objects to put methods outside works very well, and is pretty much equivalent to putting your methods inside. IIRC, theoretical work in this area has proved their equivalence. Something coming out of Sussman and Steele's realization that lambda was the same as the actor model, I believe. It makes multiple dispatch conceptually simple too.

Whichever type of object system you use, you're in pretty good shape until you use some C++/Java type OO perversion.

>>3
Forgot to add: you're doing it wrong.

>>1
what the hell's the point in having a username field without a getUsername() method?  pure data objects just sit there and DO NOTHING.  WHY DO YOU NOT WANT THEM TO DO ANYTHING?!

>>1
No, it's ENTERPRISE.

>>5
public class User {
    public String username;
}

public class Niggers {
    public static void main (String [] cocks) {
        User foo = new User();
        foo.username = "JAVA LOL";
        System.out.println(foo.username);
    }
}

>>1
No, it's perfectly fine. >>3 put it well, and from personal experience and those of my programming collegues, it's a common practice.

Oh, /prog/ is being nice for once, cheers.

>>9
GET FUCKED CUNT

>>10
Nobody here will ever obtain fucked cunt.

FUCKEDCUNTGET

if it's a class that's going to hold just one variable, i don't see what the point of using a class is when you could just deal with the variable on the top-level.

the only way i can see this being useful is if you need aliasing.

OF COURSE IT'S BAD, YOU FORGOT THE DESIGN PATTERNS

Lets write a scheme program that generates java classes and interfaces in all varying degrees of difference. Some of the classes will implement the interfaces or extend each other, some will be in packages with each other, etc.

Eventually, the UML diagram of all of our generated OOP will look like the disneyland logo.

This will be the key for the final boss of the INTERNETS.

>>15
tl;dr

>>16
OPTIMISATION