Classes that hold data have no methods (beyond getters/setters). Classes that implement behavior have no mutable state; they exist as namespaces for the functionality that they provide.
I've been quite successful with this approach. It leads to code that is easier to understand than a big ball of stateful objects.
Utter nightmare. Loads of repeated code as new programmers didn't know methods existed, loads of extraneous DTO objects, lots of nested single line methods, massive code bloat. Hard to find what actually does stuff, hard to use built in editor functionality.
It's really not a good tactic imo.
I'm undoing it as I go, at one point after having worked on it nearly 4 months according to git I'd still had a net negative on total lines of code, having added a ton of new functionality.
Admittedly, it's one of those projects which has had a bunch of freelancers/contractors work on it, but I personally really don't see what it added to move the methods off the classes apart from confusion, code duplication and code bloat.
I see the need for something, on the startup + enterprisey projects I work on you always seem to end up with at least one mega class that ends up being a beast, the Order, Person, Customer, Job or Project objects are usual culprits, but most other classes don't need much past a few basic methods. I'm just not convinced this programming tactic is it having now seen it in the wild.
Moving the methods off the classes would actually lead to less code duplication -- as now different data that need the same treatment can be handled with the same methods.
"Loads of repeated code as new programmers didn't know methods existed" seems like a bigger issue here...
That just doesn't happen enough in real life to design around.
In the rare instances when you do need to that, it's trivial to handle with interfaces and a wrapped method that calls a shared function.
On the contrary, I think it does. Especially for web, enterprise and application programming, 90% of the logic is the same tired data transformations.
Have you got any examples?
I've never had to write identical code on an Order class as a Person class. Can you give me an example of 90% of the logic being the same on an Order and a Person class?
Like in C#, the entity framework has mainly done away with all the "tired data transformations". The equivalents like Hibernate, ActiveRecord, etc. have done the same in other languages (and were the trailblazers). When I dip into a data transformation these days it's complex, hand-coded SQL, the tricky bit that takes time, with a simple data class to handle strong typing, trivial to write in a minute or two with snippets and auto-completion.
Sorry, why the complaining? We were talking on a more abstract level. Yourself just gave some anecdote about "Someone did this on a project I work on (C#). Utter nightmare. Loads of repeated code as new programmers didn't know methods existed, loads of extraneous DTO objects, lots of nested single line methods, massive code bloat", that's hardly an example either.
>I've never had to write identical code on an Order class as a Person class. Can you give me an example of 90% of the logic being the same on an Order and a Person class?
Apart from the data contained without, which process would not be the same? Most high level operations would be exactly the same: filtering would be the same (it just needs to accept a predicate), ordering would be the same, serialization would be the same, etc etc.
For a very simple example, you don't need:
persons.sort("age", sort.DESC)
orders.sort("created_at", sort.DESC)
sortedPersons = sort(persons, cur -> cur.age, sort.DESC)
sortedOrders = sort(orders, cur -> cur.created_at, sort.DESC)
db.Orders.Sort(o => o.StartDate)
Anyway, generics. Without having to muck around with funky designs for your classes.
You assert that code based on this approach is easier to understand, but you don't give a reason why this is so.
This sounds a lot like a pre-OO approach to organizing code and data, and I don't understand the benefits. To use the tried-and-true example: I want my stack state and code to go together. Why would I want to expose the stack state, and keep the code manipulating it separate?
The only caveat to this approach is that for some cases you will need a state accumulator of some sort. But those state manipulations are isolated and easy to deal with.