Approaching the Problem - Practices

A key concept that you will see me use again and again is that the client should not know about implementation. What does that mean? For example, let's define the following class:

public class EFTProcessor {
 CCPaymentService();
 
public:
 bool Execute();

private:
 EFT* SendTransaction(EFT*);
 string _paymentMethod;
 string _merchantService;
}

What we have defined is a class with one public method: Execute(). It has a private method called SendTransaction that Execute will call. It requires some values, _paymentMethod and _merchantService, that could be passed into the constructor or perhaps they were a component of our EFT datatype (which we have not yet defined). The point to this example is this: no matter what we do with SendTransaction and the EFT data type, the client can always call EFTProcessor::Execute and always get a boolean response indicating success or failure. Do not get too attached to this class, as it is only an example and will not be seen again.

The concept illustrated in the class example that we just looked at leads us to the next big concept that you will see me use: Design to an Interface, not an Implementation. This is a big one. It says that we should approach our design from the standpoint of how our objects interact, and more importantly, how our client will use them, rather than from the standpoint of how to write a specific routine. Approaching design in this fashion should lead to Loose Coupling of our design and implementation, meaning that the way in which our client interacts with our objects should be able to vary independently of how our objects complete the tasks that the client requests. Those of you who are familiar with Object Oriented Programming techniques understand that one of the purposes of this type of design, from a coding standpoint, is to facilitate polymorphism, meaning it facilitates replacing objects of one type with objects of another type transparently to the other objects that are interacting with it.