Object-Oriented – Explaining Disadvantages of HardCoding and Not Using OOP Principles

You mention two books in which one of the primary messages is "The Boy Scout Rule" i.e. clean up the code as you touch it. If you have a working system, a massive rewrite is counter-productive. Instead, as you add new functionality, make sure you improve the code as it stands.

• Write unit tests to cover the existing code that you need to change.
• Refactor that code so it is more pliable for change (making sure your tests still pass).
• Write tests for the new/revised functionality
• Write code to make the new tests pass
• Refactor as necessary.

To dive further in, Feathers talks about testing the application at its seams: the logical points at which the units connect. You can take advantage of a seam to create a stub or a mock for a dependency so that you can write tests around the dependent object. Let's take your AddressBO as an example

public class AddressBO
{
    public TransferObject GetAddress(string addressID)
    {
        if (StringUtils.IsNull(addressID))
        {
            throw new ValidationException("Address ID must be entered");
        }

        AddressDAO addressDAO = new AddressDAO();
        return addressDAO.GetAddress(addressID);
    }
}

There is an obvious seam between the AddressBO and the AddressDAO. Let's create an interface for the AddressDAO and allow the dependency to be injected into the AddressBO.

public interface IAddressDAO
{
  TransferObject GetAddress(addressID);
  //add other interface methods here.
}

public class AddressDAO:GenericDAO, IAddressDAO
{
  public TransferObject GetAddress(string addressID)
  {
    ///implementation goes here
  }
}

Now you doctor up your AddressBO to allow for injection

public class AddressBO
{
    private IAddressDAO _addressDAO;
    public AddressBO()
    {
      _addressDAO = new AddressDAO();
    }

    public AddressBO(IAddressDAO addressDAO)
    {
      _addressDAO = addressDAO;
    }

    public TransferObject GetAddress(string addressID)
    {
        if (StringUtils.IsNull(addressID))
        {
            throw new ValidationException("Address ID must be entered");
        }
        //call the injected AddressDAO
        return _addressDAO.GetAddress(addressID);
    }
}

Here we're using "poor man's dependency injection." Our only goal is to break the seam and allow us to test the AddressBO. Now in our unit tests we can make a mock IAddressDAO and validate the interactions between the two objects.

I think the most common misconception about OOP is that it's supposed to make writing software much easier. That's where some of the criticism comes from, because when writing software, OOP often means more and sometimes even less natural code. That's what makes it hard to see the benefits of OOP, as everyone who starts programming just writes new programs and never has to maintain existing ones.

However, the real benefit of OOP only shows when you have to maintain software over the years, while constantly changing parts of the program in ways nobody expected when they were first written.

You should see OOP as a way to make sure that local changes to the software stay local and don't affect the rest of the program. In this sense classes are sort of explicit placeholders for future changes. In a procedural program it is often hard to see where you have to change the code to add a completely new feature, without affecting anything else.

Surely you can write procedural programs that are also extensible, but you have to think about it and design it properly. OOP provides you with a general idea of how programs can be structured to keep them maintainable, which means that don't have to think about design that hard! The same goes for other programming paradigms, OOP isn't necessarily the just the most common right now.

So in conclusion I think the only way to really understand OOP is to change and add features to existing software. This is the most common task for programmers anyways, and it's supposed to be easy! Not having a good design makes it harder than it has to be.

That sort of makes it hard to answer your question, as any project can benefit from OOP if it's complex enough and needs to be maintained and expanded. I think projects that can have any number of unforeseen features, such games or bots would be good examples. You can also work on a open source program, that is in general the best way to practice advanced programming.