Fundamentals of OOD Part 3: Method Cohesion

re: Fundamentals of OOD Part 3: Method Cohesion

JJ — Fri, 27 Jun 2008 07:25:55 GMT

Great blog, very informative!

I have a question, what are your thoughts on creating an extension method of PerformOperation? This way PerformOperation is not 'physically' part of the Operation-derived class, however, one can still invoke it as if.

One may wonder, however, what the added value would be over just calling Execute on the object.

re: Fundamentals of OOD Part 3: Method Cohesion

PeterRitchie — Sat, 14 Jun 2008 11:44:22 GMT

Felipe, my example is very simple. I a real-world case after you perform this change you may actually want to refactor to what you've suggested. It depends on the project and depends on what you want to accomplish. "PerformOperation" isn't very descriptive and isn't very intention-revealing; so, yes, simply calling the Operation-derived class directly may be a valid refactoring. If "PerformOperation" has a more descriptive name--being more intention revealing--then refactoring to just calling the Operation-derived class directly would likely make the code less clear.

re: Fundamentals of OOD Part 3: Method Cohesion

Felipe Fujiy Pessoto — Fri, 13 Jun 2008 19:44:51 GMT

Peter, answer my question please

re: Fundamentals of OOD Part 3: Method Cohesion

PeterRitchie — Fri, 13 Jun 2008 13:42:56 GMT

Assam, I'm glad they help.

The factory pattern implements no business logic (the policy) the Strategy pattern does implement business logic. You could use a factory pattern to decouple the code that uses an Operation implementation from the various implementations; but then you'd be using Factory and Strategy.

No, the Factory pattern and the Strategy pattern are not interchangeable. Factory merely abstracts the creation of objects. Strategy encapsulates and abstracts policy.

re: Fundamentals of OOD Part 3: Method Cohesion

Assam — Fri, 13 Jun 2008 12:15:54 GMT

Hello, your blogs always make a dumb like me to understand things in such a simpler way. So i say thanks to you. After reading this i actually questioned my senior and asked him what pattern would he use in the scenario you presented. He said he would use factory pattern(though i dont agree). His stance was that Strategy and Factory patterns are quite similar so they can be use interchangeably. My question is can factory pattern be used for the problem you presented.

re: Fundamentals of OOD Part 3: Method Cohesion

Felipe Fujiy Pessoto — Thu, 12 Jun 2008 01:56:45 GMT

I have a question. In the end, which serves the PerformOperation?

I can just do:

Operation operation = new AndOperation();

IList<int> = operation.Execute(left, right);

Sorry for bad english

Ty.

re: Fundamentals of OOD Part 3: Method Cohesion

PeterRitchie — Wed, 11 Jun 2008 14:05:20 GMT

Steve, yes, Intersection and And are the same (which makes the fact that my Innersection code and my And code are different all the more stranger :-).

re: Fundamentals of OOD Part 3: Method Cohesion

Steve — Wed, 11 Jun 2008 09:33:19 GMT

But that means Intersection and And are the same :)

But that wasn't the point I know :D

Great article, I just wish more developers would know this :(

re: Fundamentals of OOD Part 3: Method Cohesion

PeterRitchie — Wed, 11 Jun 2008 01:58:58 GMT

Eyal-Shilony. Good question. I chose an abstract class over an interface because I think it's more clear in this circumstance. It's more clear that the strategy implementation is expected to do only one thing.

I this case it does only one thing, we don't use other classes that might do other things so rather than over-design we use the simplest thing that fulfills our requirements. Should you want to have a class that can fulfill more than one interface contract then use of interface might be more appropriate. I generally think that implementing more than one interface likely means the class is violating SRP. In this case we're more likely to implement a class that has a single responsibility because it can only have one base (the abstract Operation).

But, yes, interface could have just as easily been used.

re: Fundamentals of OOD Part 3: Method Cohesion

PeterRitchie — Wed, 11 Jun 2008 01:53:38 GMT

Steve, good question. You're obviously paying attention :-).

Yes, you don't need that second loop, I'll remove it.

re: Fundamentals of OOD Part 3: Method Cohesion

Eyal-Shilony — Wed, 11 Jun 2008 00:55:36 GMT

Hello, first I would like to say that you inspire me, your blogs are enjoyable. :)

The "Operation" type contain no implementations, so I wonder for the reason you used abstract class over an interface, can you enlighten me with reason ? or was it just for the example ? (silly as it may sound).

Thank you for your time, regards!

re: Fundamentals of OOD Part 3: Method Cohesion

Steve — Tue, 10 Jun 2008 22:39:33 GMT

Great post, but for the AndOperation, isn't the second foreach unnecessary? Since it has to be in BOTH it's enough to just check one collection, in other words, there will never be an item that will be added in the second foreach :)

Fundamentals of OOD, method cohesion

DotNetKicks.com — Tue, 10 Jun 2008 19:58:18 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com