With this post I’d like to introduce a new concept in programming:
The person oriented programming (POP) or Polite Object Oriented Programming (POOP).
I haven’t decided on the name yet, although the last acronym doesn’t sound quite as good, I guess. 🙂
Anyway, what is it all about?
The main idea is to treat all your classes, not as a dumb object that you can treat as you like, but as a person you ask things to do for you.
These are the main rules for Person oriented programming:
1. Be Polite
Often, objects are being treated as a stupid property bag. We just use the setters to put the object in the state we want it to be. That is not very polite.
It’s like a dictator commanding his subjects to change immediately, whether they want to or not. So, using properties to make an object change state, is a bit dictatorial or evil.
I think it’s better to treat an object as a person, and ask it if it wants to change state. Then the object can check if it is able, and wants to handle your request. And reply to you accordingly. Either with a simple boolean (Yes, ‘I did what you asked me to do’. Or ‘No, I can’t/don’t want to’) or a more complex reply with some extra explanations why it didn’t handle your request.
No I can’t: is like asking an object to read a file and you pas an invalid path.
No, I don’t want to: is like asking an object to set a period end date to a value before the period start date.
Of course, some objects are really nothing but a bunch of properties that require no extra logic. These can still be treated as dumb objects.
But as soon as some intelligence is present in the object (apart from simple notify property changed logic), it’s not an object any more. It’s alive!
It can think and make decisions, so you should treat it as an intelligent thing and you should communicate with it.
These intelligent classes should have read-only properties and public methods for actions and to change the state.
I would almost suggest imposing a naming convention to make every method start or end with Please. (PleaseActivateYourself or ActivateYourselfPlease), and reply with a Reply-enumeration
public enum Reply
{
OK,
Sorry,// Sorry, I can't
NoThanks// No, I don't want to
}but that’s maybe one or two bridges to far. 🙂
2. Specify the person’s profession
When naming the class, make sure to give it a proper name. Reflecting the function of the person (class) in your organisation (project). Is he/she a mediator, a calculator, a writer, a logger, …
Make sure the name sounds like a responsability/profession. The more you can make the structure of your program look and sound like a company, the easier it is to understand.
3. And only one profession
When you find it difficult to pick a good name for a class, because it’s doing lot’s of stuff, take a step back. Chances are your class is doing to much and is violating the Single Reponsibility Principle (SRP): One class should do one thing, and one thing only.
I once saw a very good real life example of this in Tanzania. We were travelling through the country by car and had to refuel. In the gas station we were served by three guys: One guy filled the gas tank, another one received the money and brought it to the guy managing the cash and the POS. The second guy then received the change and brought it back to us.
So, in the GasStation-application you’d have the Refueler, the CashTransporter and the PosManager classes.