exceptionz

Thoughts on Technology, Methodology and Programming.

Archive for the ‘OO’ Category

You can now build the source code in either VS2k5 or VS2k8

Posted by Marcus Wyatt on 11 March 2008

I’ve updated the source code to include some conditional compilation directives to support different Visual Studio IDE versions. So if you are still stuck in VS2005 land, you can now build the source and be able to take advantage of the new features that Owen Evans added.

These include the new attributes (Context, BeforeAll, BeforeEach, AfterAll, AfterEach) and new functionality like Collection.Contains#WithProperty. If you lucky to be using VS2008 you’ll have new functionality that allows you to pass lambda’s. For more information look at http://bgeek.net/2008/02/14/nspecify-rspec-well-closer-anyway/

Owen also added a new library called NSpecify.Framework.Extensions. This gives you some extension methods that you can use to specify your expectations directly on the object under test.

i.e. newDeveloper.Surname.Must().Equal(“Evans”);

Nice hey!

Posted in BDD, Development, OO, Software, TDD, Tools | Tagged: , , | Leave a Comment »

How to solve a domain object problem with Object Orientation.

Posted by Marcus Wyatt on 6 November 2007

Who cares about Domain Rules?

This article shows how you can solve a domain problem, with several different solutions. You’ll find six different solutions where I have explored each solution using exactly the same problem. I’ve always said that there is no wrong way to develop code. What do I mean by that? Well, you could solve a problem in several ways.

read more | digg story

Posted in Development, OO | Tagged: , | Leave a Comment »

Links for 29 October 2007(Rails, Dsl, JavaScript, CSS, TextMate)

Posted by Marcus Wyatt on 29 October 2007

Rails

Domain Specific Language

JavaScript

CSS

Web General

Technorati Tags: , , , ,

Powered by ScribeFire.

Posted in CSS, JavaScript, OO, RoR, TextMate | Leave a Comment »

Introduce Behavior-Driven Development without much resistance…

Posted by Marcus Wyatt on 17 September 2007

Within the .NET community the idea of test-driven development is starting to become common knowledge. This doesn’t necessarily mean that it is practiced. I believe that although many people find the idea of TDD very easy to grok, they find the implementation of TDD very hard and many revert back to their old ways of working soon after trying TDD.

So why is TDD so hard?

I don’t think that it is only one aspect that makes TDD hard, but a culmination of many factors together. Firstly, you should have a good understanding of OO. You need to understand how to de-couple your objects. How to isolate the class under test by mocking or stubbing the external dependencies. If you are one of those developers that write huge methods with multiple lines of code, then I’m afraid you are not going to be able to practice TDD.

There is also old habits. It is hard to kick old habits, like I can profess when I stopped smoking a couple of years ago. But with perseverance you can loose those old habits.

The other problem is of course the vocabulary you use during a TDD session. All the words you work with has their grounding in validation. i.e. Test, TestFixture, Assert, etc. This makes it quite hard to focus your attention on what you are really doing, specifying the functionality (behavior) of the object. It’s quite simple to see that if I talk about writing a test for the Order object and I assert that the order should be filled, that the language I use isn’t very helpful in making me think about the behavior of the Order. But if I’m writing a specification for the order to specify that an order can be filled, then suddenly my language doesn’t create a barrier.

So what do you mean by ‘introduce BDD without much resistance’?

Wel, in .NET you have the ability to alias and that ability is what I’m using to create an easy why to change the nomenclature of your code. Here is a example of what I’m talking about:

 

    3 using NSpecify.Framework;

    4

    5 using Rhino.Mocks;

    6

    7 using SetupResources = NUnit.Framework.SetUpAttribute;

    8 using DestroyResources = NUnit.Framework.TearDownAttribute;

    9 using Functionality = NUnit.Framework.TestFixtureAttribute;

   10 using Specification = NUnit.Framework.TestAttribute;

   11

   12 [Functionality(Description="Describe the functionality of the order domain object.")]

   13 public class OrderFunctionality

   14 {

   15     private MockRepository mockery;

   16     private IWarehouse warehouse;

   17

   18     [SetupResources]

   19     public void BeforeSpecificationExecute()

   20     {

   21         mockery = new MockRepository();

   22

   23         // setup the warehouse mock

   24         warehouse = mockery.CreateMock<IWarehouse>();

   25     }

   26

   27     [DestroyResources]

   28     public void AfterSpecificationExecuted()

   29     {

   30         mockery.VerifyAll();

   31     }

   32

   33     [Specification(Description="Should not be able to fulfill order.")]

   34     public void ShouldNotBeAbleToFulfillOrder()

   35     {

   36         string product = “Harry Potter and the Deathly Hollows”;

   37

   38         Order order = new Order(product, 50);

   39

   40         mockery.Record();

   41

   42         Expect.Call(warehouse.GetInventory(product)).Return(10);

   43

   44         mockery.ReplayAll();

   45

   46         order.Fill(warehouse);

   47

   48         Specify.That(order.IsFilled).Must.Equals(false);

   49     }

   50     [Specification(Description = "Should be able to fulfill order successful.")]

   51     public void ShouldBeAbleToFulfillOrder()

   52     {

   53         string product = “Harry Potter and the Order of the Phoenix”;

   54

   55         Order order = new Order(product, 50);

   56

   57         mockery.Record();

   58

   59         Expect.Call(warehouse.GetInventory(product)).Return(61);

   60

   61         mockery.ReplayAll();

   62

   63         order.Fill(warehouse);

   64

   65         Specify.That(order.IsFilled).Must.Equals(false);

   66     }

   67 }

As you can see from reading the code snippet above, by using aliasing we are able to change the language we use. The cool thing about aliasing the NUnit attributes, is that your current build script or the tools you use to run your tests would still work effortlessly. But, now we are reading and thinking in terms of specifications and not tests. Cool Hey!

If you are wondering how I’m able to write Specify.That then you should check out NSpecify.

Technorati Tags: ,

Powered by ScribeFire.

Posted in BDD, Development, OO, TDD | 1 Comment »

Inversion of Control tutorial

Posted by Marcus Wyatt on 2 May 2007

I’ve found these great tutorials on IoC written by Alex Henderson.

Part 1 – Simple configuration
Part 2 – Array Configuration
Part 3 – Dictionary configuration
Part 4 – Switching configurations
Part 5 – Configuration parameters
Part 6 – Switching between lifestyles
Part 7 – Switching implementations
Part 8 – Referencing implementations by key
Part 9 – Constructor Injection
Part 10 – Setter Injection
Part 11 – Factories
Part 12 – Decorators
Part 13 – Injecting Service Arrays
Part 14 – Startable Facility

Great job!

Technorati Tags: ,

Powered by ScribeFire.

Posted in Development, OO, Software | 1 Comment »

Why abstracting presentation logic is critical!

Posted by Marcus Wyatt on 13 March 2007

I’ve been listening to the Design Patterns Bootcamp podcast where they discussed the Model-View-Controller and Presenter patterns. In the podcast they pointed to “Should validation be in the UI or in business objects” post by Rockford Lhotka. He made the following comments that really struck a nerve with me:

In any case, I do focus greatly on keeping code out of the UI. There’s nothing more expensive than a line of code in the UI – because you _know_ it has a half-life of about 1-2 years. Everyone is rewriting their ASP.NET 1.0 UI code to ASP.NET 2.0. Everyone is tweaking their Windows Forms 1.0 code for 2.0. And all of it is junk when WinFX comes out, since WPF is intended to replace both Windows and Web UI development in most cases. Thus code in the UI is expensive, because you’ll need to rewrite it in less than 2 years in most cases.

Code in a business object, on the other hand, is far less expensive because most business processes don’t change nearly as fast as the UI technologies provided by our vendors… As long as your business objects conform to the basic platform interfaces for data binding, they tend to flow forward from one UI technology to the next. For instance, WPF uses the same interfaces as Windows Forms, so reusing the same objects from Windows Forms behind WPF turns out to be pretty painless. You just redesign the UI and away you go.

I completely agree with Rocky and believe that development teams that doesn’t abstract their presentation logic out of their code behind of their pages or winforms, will unfortunatly not be able to compete with teams that have. This would be due to the low velocity at which they can produce new functionality with new technology, due to their tight coupling of UI and presentation logic. By abstracting your presentation logic away from the presentation medium (i.e. webforms or winforms) you would be able to replace the presentation medium very easily when a new technology (i.e. WPF) arrive. This will allow you to upgrade your application and take advantage of the new functionality by re-using your existing presentation logic.

What do you think?

tags:

Currently listening to: Timo Maas – Killin’ Me

Posted in Development, OO | 1 Comment »

Everything you know is wrong

Posted by Marcus Wyatt on 5 May 2006

While I was searching for more information on Behaviour Driven Development, I ended up at Dave Astels blog. Now, many of you in the same headspace as me would probably point out that Dave is one of the pioneering thinkers in this area. Rightly so, but what I found was an interesting post regarding Agile. The first line of the post reads as follows:

I’m in Allen Holub’s talk this morning… “Everything you know is wrong: Inheritance and getters/setters are evil”.

When I read this statement, I found myself almost instantly offended. How can you make a statement like this? Do you want to tell me most of the other leading technical thinkers are WRONG? I mean, come on… We have been practicing Object-Orientation since the middle eighties and all our languages today is build to enable us to develop Object-Oriented software. I continued to read the post and then I found this paragraph:

Allen started off with the classic “tell, don’t ask” talk. He makes a very good point that hadn’t occurred to me before. To really get benefit out of an Agile process (specifically XP) you NEED to be doing OO properly. If you aren’t, you will fail.

I have made this exact point a while back when we where discussing Test-Driven Development. As any TDD zealot knows, you cannot effectively do test-driven development without having loosely coupled objects. Why? The reason is that when you are test-driving a piece of behaviour, you want to be able to test the behaviour in isolation. And to be able to do that, you need to Mock out external dependencies, and to mock the dependencies, you need to expose the dependencies as an interfaces. This brings me back, to another point. State based vs. Interaction based testing. When I started to get into TDD a few years back, I found doing Test-Driven Development was really-really hard. Why? Because I was only doing, state based testing. Since I learned to think in terms of the behaviour that I am trying to implement, I found writing the specifications (tests) are easier and my objects became more cohesive. On to the next interesting bit:

Next Allen moved to why encapsulation is so important and why getters & setters are such a problem. Don’t bother getting flustered about that idea.. he’s 100% on the money. If you disagree you need to learn what OO is. One nice soundbite: “Doing it this way (interface based, using design patterns) lets me have to think less. Thinking is hard… I’d rather just program.”

I agree with Dave on this one. Take for instance the Command-query Separation principle, as soon as you know and understand the principle, you consciously try to adhere to the rules of the principle. By doing this, your code starts to have less public properties and you get methods that are performing only one responsibility. I’m not trying to say that the Command-query Separation principle is the solution to the problem, but that knowledge of Object-Oriented principles will lead you to writing better, more bullet prove code. The Command-query Separation principle is only one in a multitude of Object-Oriented principles.

The bottom line(s):

  1. There is no such thing as perfect
  2. Design is a series of trade-offs
  3. assess risk, then make reasonable decisions
  4. there’s often is a better way of doing things than the first way you think of

tags: , , ,

Posted in BDD, OO, TDD, XP | Leave a Comment »

Code Smell: CallSuper

Posted by Marcus Wyatt on 12 August 2005

CallSuper is a minor smell (or anti-pattern if you like) that crops up from time to time in OO frameworks. Its symptoms are pretty easy to spot. You are inheriting from a super-class in order to plug into some framework. The documentation says something like “to do your own thing, just subclass the process method. However it’s important to remember to start your method with a call to the super-class”.

An example might be something like this.

public class EventHandler {
   public void handle (BankingEvent e){ 
      housekeeping(e); 
   } 
}
public class TransferEventHandler extends EventHandler {
   public void handle(BankingEvent e) { 
      super.handle(e); 
      initiateTransfer(e); 
   }
}

Whenever you have to remember to do something every time, that’s a sign of a bad API. Instead the API should remember the housekeeping call for you. The usual way to do this is to make the handle method a Template Method, like this. 

public class EventHandler {
   public void handle (BankingEvent e) {
      housekeeping(e);
      doHandle(e);
   }
}
 
protected void doHandle(BankingEvent e) {
 
}
 
public class TransferEventHandler extends EventHandler {
   protected void doHandle(BankingEvent e) {
      initiateTransfer(e);
   }   
}

Here the super-class defines the public method and provides a separate method (often referred to as a hook method) for the subclass to override. The subclass writer now doesn’t have to worry his ugly head about calls to super. Furthermore the super-class writer is free to add calls after the subclass method if she wishes.

You can read Martin Fowler’s whole post here.

tags: , ,

Currently listening to: a, Part II – Winamp *** 2. Ayla – Ayla, Part II

Posted in OO, Refactoring | Leave a Comment »

The two Cornerstones of Object-Oriented Programming

Posted by Marcus Wyatt on 12 August 2005

Coupling and Cohesion: The Two Cornerstones of OO Programming: “by Samudra Gupta

In this informative tutorial, you are introduced to code metrics that will help you measure how well your classes conform to the principles of Coupling and Cohesion.

For Cohesion, the “Lack of Cohesion in Methods” metric helps you understand and gauge how cohesive your class is and “Demeter’s Law” helps with Measuring Coupling between your classes.

I think if we can use these types of metrics to understand our code better and even try to incorporate them as part of our testing suite or productivity tools, we will make a huge improvement in building more flexible solution.

Like the author said:

“Make no mistake, these metrics are vital to measuring the quality of an application.”

tags: , ,

Currently listening to: g (kevin roen nye 2001 remix) – Winamp *** 367. atb vs. pqm – let u go vs. you are sleeping (kevin

Posted in Development, OO | 1 Comment »

Code Level Encapsulation Guidelines for Business Service Objects

Posted by Marcus Wyatt on 25 May 2005

1I’ve found this extremely informative article on Designing Efficient Business Service Objects and in the article the author noted the following Guidelines for Code Encapsulation that he follows when developing his Service Objects.

Code Level Encapsulation Guidelines

  1. Object encapsulation is at the forefront of consideration.
  2. Use Interfaces to create object contracts
  3. Follow descriptive naming conventions for all classes and methods.
  4. If an object contains more than 3 public methods (other than accessor methods) then it is a sign that the object is not sufficiently encapsulated, particularly controller classes which I many times limit to just 1 public method.
  5. Refrain from passing raw data into methods. Rather favor objects as parameters.
  6. Limit method parameters to 3 or less unless there is compelling reason for more. Most times a method that needs more parameters is not encapsulated and needs to be broken up into other methods.
  7. Limit method body text to what is easily seen in one screen.
  8. Limit each method to one specific discrete operation regardless of how small, even if the operation is not called from multiple other places in the class.
  9. Provide verbose and detailed JavaDoc comments no matter how trivial the method.
  10. JavaDoc all method parameters, returns, and exceptions.
  11. Do not nest conditional logic more than 2 levels; more indicates the need to break out into another method call.
  12. Consolidate all class functionality (i.e. business purpose and process) in one main public method which calls out to other methods in the class to do the work.
  13. Do not nest method calls more than 2 layers deeper then from the main public method (i.e. main public calls method1 which in turn calls method2 – but method2 is not allowed to cascade further).
  14. Try not to go more than 3 levels of inheritance before getting to your concrete class.
  15. Rather than using inheritance hierarchies to facilitate business solution responsibility, modern Object Oriented Design technology suggests combining aggregation (has a) with composition (is a type of) within inheritance hierarchies. For example, pure inheritance might have an ancestor class Person with an Employee descendant which might in turn subclass an HourlyWorker. But HourlyWorker “is a type of” Employee, not an “is a” Employee. Thus, Person will extend Employee but Employee will have an aggregate abstract EmployeeType which will then extend HourlyWorker, SeasonalWorker, etc. as descendants. Deep inheritance hierarchies tend to be quite bloated and clog up the pipe with excess object overhead and referencing through the stack. They can also be quite difficult to understand from a maintenance perspective with later developers coming into the system.

After reading the whole article I think these rules does apply in a big way. What do you think?

tags: , ,

Currently listening to: ** 79. Arksun – Astrodancer – Winamp ***

Posted in Development, OO | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.