Comments on: How to think about OO

By: Making Zend_Auth more “Object Oriented” | Aviblock.com

Making Zend_Auth more “Object Oriented” | Aviblock.com — Fri, 30 Oct 2009 01:15:00 +0000

[...] controller. I knew there had to be a better way. So after a lot of thought, pondering, reading, and inspiration, this is what I’ve come [...]

By: misko

misko — Fri, 18 Sep 2009 14:08:55 +0000

@John,

The issues in this example is that a static method is fixed at compile time and will always return the same kind of object. This does not help you in testing as you want to return a different kind. For example you want AlwaysAuth class rather than LDAPAuth class. Static method can not make this decision unless there is global state, which is very bad way to solve this problem. So static factory method buys you nothing.

– Misko

By: John Januszczak

John Januszczak — Fri, 18 Sep 2009 11:38:47 +0000

Mikso,

Below is an example of what I am talking about. When the factory method is implemented, I often see it implemented as a static method (and often in what might as well be a static class). Look at the examples in this article to see what I was getting at:

http://en.wikipedia.org/wiki/Factory_method_pattern

By: Sam

Sam — Wed, 09 Sep 2009 15:25:18 +0000

Hi Misko,
You mentioned that some languages offer extension methods. The language I work with, C#, indeed does offer this. However, it should be noted that you can’t mock extension methods, so you’ll need to manually write a test double for dependencies with extension methods (assuming you need to call such methods in your tests).
… of course now that I think about it, perhaps extension methods are best used only with newables, and if an injectable needs to be extended it gets Decorated.

By: peter

peter — Mon, 07 Sep 2009 00:08:43 +0000

Hey!
Wonderful as usual. For completness could you please further explain something.
You got rid of the “If”s by using polymorphisim (creating the SuperUser etc). My question is … How would you use this in code. Could you show (if possible) how you would structure the code that uses each of the user types. Will there stil lbe an “If” or “switch” that returns new SuperUser.. or new User??
I hope my question made sense.
Thank you for sharing this wealth of information.

By: Przemek

Przemek — Wed, 12 Aug 2009 21:17:40 +0000

Misko, you often stress, that objects should not call factory.get(). In most cases it’s better to ask for collaborators in constructor.

However, what if I really need to create objects as a part of request processing? Sometimes I have not enough data to create them beforehand.

Example: user submits his postal address via a web form. Depending on the address I will display an optimal shipping strategy (each strategy can execute different business process). The most natural way for me to implement it is to call shipping=factory.get(address), and then shipping.display()

That would be however calling factory from my objects, that you don’t advise. How would you approach such problem?

By: misko

misko — Wed, 12 Aug 2009 17:43:32 +0000

@John,

how can they be static? A factory should have a get() method with zero arguments (most of the time). This means that it will always create the same thing (unless there is global state, or same parameters get passed in through the factory constructor.). Are your objects calling factory.get()? (bad) or are they simply asking for the dependencies in the constructor? (good). Look at GUICE and how it solves the factory problem.

– misko

By: John Januszczak

John Januszczak — Wed, 12 Aug 2009 17:04:17 +0000

Misko, I understand the problem with static methods. I also understand that another OO principle you advocate is separation of object creation from object logic. So you have object factories, and all the “if” statements can be relegated there allowing you to avoid these conditionals in your object logic by using polymorphism (as described in this post in the case of the User classes).

When you do all this, what I end up seeing a lot of times is a static factory method (often inside a dedicated static – or might as well be static – factory class). What’s the proper approach here? Specifically, where does the User factory go in your example so that we don’t end up with a static factory method and/or class?

By: Przemek

Przemek — Tue, 11 Aug 2009 10:56:09 +0000

@Val Karpov
If you want to properly test logoutIfFlyingArtichoke, you often want to mock its collaborators to check if only proper functions were called. That leaves you two options IMO, each with its problems. You either subclass User and throw exceptions (poor solution IMO) or use ISP (and worry about functional approach in Java: not a problem for me). Of course, you can make logout static, but how are you going to mock it to prevent its side-effects and to check whether it was called?
Finally, I don’t know your case, but I think worrying about unexpected calls to a method from another one is unnecessary in many cases.

By: Val Karpov

Val Karpov — Mon, 10 Aug 2009 17:23:28 +0000

@Przemek
That can quickly get really bad really quickly – you can end up with an interface for every function defined in your class, public class User implements Login, Logout, etc. which basically leaves you trying to hack Java into being a functional language.