Return to Answer

I'm late to the party but going to throw this anyway since its ended up a massive discussion.

There is no definition of a "getter" because its not what it does, but how you use it that's the problem.

When people say "getters are bad" what they mean is you are writing in an Anemic Domain Object style where you put your methods on services and read data from your objects. ie.

public class Account { public int Amount {get;set;} public string CurrencyCode {get;set;} } public class CashMachine { public AddFunds(accountId, amount) { var a = repo.GetAccount(accountId) a.Amount += amount; repo.Save(account); } } 

And you should be writing in an OOP way. ie.

public class Account { private int Amount private string CurrencyCode public AddFunds(amount) { this.Amount += amount; } } 

With no public Amount getter, you would be forced to use the OOP approach. So "avoid getters" is a good general rule to flag up when you might be straying from OOP.

However.

If you really don't expose any properties at all you start doing other things which are also considered bad. ie.

public class Account { private int Amount private string CurrencyCode public Save() //ooo coupling to datalayer! { this.database.execute("insert into..."); } public Display() //ooo coupling to presentation layer! { this.detailView.Update(... } } 

What's happening is that how people program in real life is a mishmash of different styles which all have a bunch of simple rules like "avoid getters" meant to help you understand the principle behind that style. They aren't meant to be taken to the nth degree and they aren't supposed to be non-contradictory with other style rules or even each other.

Robert Bräutigam has answered the question directly about his articles, so you can read the truth there, but it seems to me like he's saying "You can take the rule further than you think, push yourself harder to write in the OOP style"

This is really a challenge to the reader rather than a proof of OOPs superiority over other styles. Try putting Display() on Account is it really that bad? look at the advantages, don't assume it won't work.

I'm my view people often don't try things out, they take a bit of each style that they like and dismiss the rest "it would never work!", "the example is a strawman!". You need to take some time and try out what the article is suggesting before going back to everyone's favourite the superior ADO style

I'm late to the party but going to throw this anyway since its ended up a massive discussion.

There is no definition of a "getter" because its not what it does, but how you use it that's the problem.

When people say "getters are bad" what they mean is you are writing in an Anemic Domain Model style where you put your methods on services and read data from your objects. ie.

public class Account { public int Amount {get;set;} public string CurrencyCode {get;set;} } public class CashMachine { public AddFunds(accountId, amount) { var a = repo.GetAccount(accountId) a.Amount += amount; repo.Save(account); } } 

And you should be writing in an OOP way. ie.

public class Account { private int Amount private string CurrencyCode public AddFunds(amount) { this.Amount += amount; } } 

With no public Amount getter, you would be forced to use the OOP approach. So "avoid getters" is a good general rule to flag up when you might be straying from OOP.

However.

If you really don't expose any properties at all you start doing other things which are also considered bad. ie.

public class Account { private int Amount private string CurrencyCode public Save() //ooo coupling to datalayer! { this.database.execute("insert into..."); } public Display() //ooo coupling to presentation layer! { this.detailView.Update(... } } 

What's happening is that how people program in real life is a mishmash of different styles which all have a bunch of simple rules like "avoid getters" meant to help you understand the principle behind that style. They aren't meant to be taken to the nth degree and they aren't supposed to be non-contradictory with other style rules or even each other.

Robert Bräutigam has answered the question directly about his articles, so you can read the truth there, but it seems to me like he's saying "You can take the rule further than you think, push yourself harder to write in the OOP style"

This is really a challenge to the reader rather than a proof of OOPs superiority over other styles. Try putting Display() on Account is it really that bad? look at the advantages, don't assume it won't work.

I'm my view people often don't try things out, they take a bit of each style that they like and dismiss the rest "it would never work!", "the example is a strawman!". You need to take some time and try out what the article is suggesting before going back to everyone's favourite the superior ADM style

I'm late to the party but going to throw this anyway since its ended up a massive discussion.

There is no definition of a "getter" because its not what it does, but how you use it that's the problem.

When people say "getters are bad" what they mean is you are writing in an Anemic Domain Object style where you put your methods on services and read data from your objects. ie.

public class Account { public int Amount {get;set;} public string CurrencyCode {get;set;} } public class CashMachine { public AddFunds(accountId, amount) { var a = repo.GetAccount(accountId) a.Amount += amount; repo.Save(account); } } 

And you should be writing in an OOP way. ie.

public class Account { private int Amount private string CurrencyCode public AddFunds(amount) { this.Amount += amount; } } 

With no public Amount getter, you would be forced to use the OOP approach. So "avoid getters" is a good general rule to flag up when you might be straying from OOP.

However.

If you really don't expose any properties at all you start doing other things which are also considered bad. ie.

public class Account { private int Amount private string CurrencyCode public Save() //ooo coupling to datalayer! { this.database.execute("insert into..."); } public Display() //ooo coupling to presentation layer! { this.detailView.Update(... } } 

What's happening is that how people program in real life is a mishmash of different styles which all have a bunch of simple rules like "avoid getters" meant to help you understand the principle behind that style. They aren't meant to be taken to the nth degree and they aren't supposed to be non-contradictory with other style rules or even each other.

Robert Bräutigam has answered the question directly about his articles, so you can read the truth there, but it seems to me like he's saying "You can take the rule further than you think, push yourself harder to write in the OOP style"

I'm late to the party but going to throw this anyway since its ended up a massive discussion.

There is no definition of a "getter" because its not what it does, but how you use it that's the problem.

When people say "getters are bad" what they mean is you are writing in an Anemic Domain Object style where you put your methods on services and read data from your objects. ie.

public class Account { public int Amount {get;set;} public string CurrencyCode {get;set;} } public class CashMachine { public AddFunds(accountId, amount) { var a = repo.GetAccount(accountId) a.Amount += amount; repo.Save(account); } } 

And you should be writing in an OOP way. ie.

public class Account { private int Amount private string CurrencyCode public AddFunds(amount) { this.Amount += amount; } } 

With no public Amount getter, you would be forced to use the OOP approach. So "avoid getters" is a good general rule to flag up when you might be straying from OOP.

However.

If you really don't expose any properties at all you start doing other things which are also considered bad. ie.

public class Account { private int Amount private string CurrencyCode public Save() //ooo coupling to datalayer! { this.database.execute("insert into..."); } public Display() //ooo coupling to presentation layer! { this.detailView.Update(... } } 

What's happening is that how people program in real life is a mishmash of different styles which all have a bunch of simple rules like "avoid getters" meant to help you understand the principle behind that style. They aren't meant to be taken to the nth degree and they aren't supposed to be non-contradictory with other style rules or even each other.

Robert Bräutigam has answered the question directly about his articles, so you can read the truth there, but it seems to me like he's saying "You can take the rule further than you think, push yourself harder to write in the OOP style"

This is really a challenge to the reader rather than a proof of OOPs superiority over other styles. Try putting Display() on Account is it really that bad? look at the advantages, don't assume it won't work.

I'm my view people often don't try things out, they take a bit of each style that they like and dismiss the rest "it would never work!", "the example is a strawman!". You need to take some time and try out what the article is suggesting before going back to everyone's favourite the superior ADO style

I'm late to the party but going to throw this anyway since its ended up a massive discussion.

There is no definition of a "getter" because its not what it does, but how you use it that's the problem.

When people say "getters are bad" what they mean is you are writing in an Anemic Domain Object style where you put your methods on services and read data from your objects. ie.

public class Account { public int Amount {get;set;} public string CurrencyCode {get;set;} } public class CashMachine { public AddFunds(accountId, amount) { var a = repo.GetAccount(accountId) a.Amount += amount; repo.Save(account); } } 

And you should be writing in an OOP way. ie.

public class Account { private int Amount private string CurrencyCode public AddFunds(amount) { this.Amount += amount; } } 

With no public Amount getter, you would be forced to use the OOP approach. So "avoid getters" is a good general rule to flag up when you might be straying from OOP.

However.

If you really don't expose any properties at all you start doing other things which are also considered bad. ie.

public class Account { private int Amount private string CurrencyCode public Save() //ooo coupling to datalayer! { this.database.execute("insert into..."); } public Display() //ooo coupling to presentation layer! { this.detailView.Update(... } } 

What's happening is that how people program in real life is a mishmash of different styles which all have a bunch of simple rules like "avoid getters" meant to help you understand the principle behind that style. They aren't meant to be taken to the nth degree and they aren't supposed to be non-contradictory with other style rules or even each other.

I'm late to the party but going to throw this anyway since its ended up a massive discussion.

There is no definition of a "getter" because its not what it does, but how you use it that's the problem.

When people say "getters are bad" what they mean is you are writing in an Anemic Domain Object style where you put your methods on services and read data from your objects. ie.

public class Account { public int Amount {get;set;} public string CurrencyCode {get;set;} } public class CashMachine { public AddFunds(accountId, amount) { var a = repo.GetAccount(accountId) a.Amount += amount; repo.Save(account); } } 

And you should be writing in an OOP way. ie.

public class Account { private int Amount private string CurrencyCode public AddFunds(amount) { this.Amount += amount; } } 

With no public Amount getter, you would be forced to use the OOP approach. So "avoid getters" is a good general rule to flag up when you might be straying from OOP.

However.

If you really don't expose any properties at all you start doing other things which are also considered bad. ie.

public class Account { private int Amount private string CurrencyCode public Save() //ooo coupling to datalayer! { this.database.execute("insert into..."); } public Display() //ooo coupling to presentation layer! { this.detailView.Update(... } } 

What's happening is that how people program in real life is a mishmash of different styles which all have a bunch of simple rules like "avoid getters" meant to help you understand the principle behind that style. They aren't meant to be taken to the nth degree and they aren't supposed to be non-contradictory with other style rules or even each other.

Robert Bräutigam has answered the question directly about his articles, so you can read the truth there, but it seems to me like he's saying "You can take the rule further than you think, push yourself harder to write in the OOP style"