Using SRP with Object Thinking

Question

According to David West, Object Thinking involves identifying Objects in the problem/business domain that mirror real-world objects; the interface would then reflect the behaviors of that object.

What would happen if we had an object class with alot of different behaviors. How would that not violate the Single Responsibilty Principle?

For instance, take an OrderBatch class with the following interface:

public class OrderBatch{

    public Customer getCustomer(){...};

    public void addOrder(){...}

    public void removeOrder(Order order){...}

    public List<Order> getOrders(){...}

    public void queueForPicking(){...}

    public void markComplete(){...}

    public void printPicklist(){...}

    public void emailPicklist(){...}        

}

These methods all seem to be behaviors you would expect from an OrderBatch.

Now imagine the above interface together with all the implementation code needed to make this work, and you have a Super-Duper God Class.

Is this a violation of the SRP? Why should it be, if these behaviors belong to that object? And if it is a violation, how would I split it?

Answer 1

There is a difference between a thing and things related to that thing. To illustrate, consider your example:

public class OrderBatch{
    public Customer getCustomer(){...};
    public void addOrder(){...}
    public void removeOrder(Order order){...}
    public List<Order> getOrders(){...}
    public void queueForPicking(){...}
    public void markComplete(){...}
    public void printPicklist(){...}
    public void emailPicklist(){...}        
}

Why wouldn't this be more like this?

public class OrderBatch{
    public int CustomerID;
    public int BatchID;
    public void removeOrder(Order order){...}
    public void markComplete(){...}
}

public class CustomerRepository {
    public Customer getCustomer(int customerID);
}

public class Order {
    public void AddToBatch(int batchID)
}  

public class OrderRepository {
    public Order[] getOrdersByBatchID(int batchID)
}

public class OrderQueue {
    public void Add(OrderBatch batch)
}

public class PickList {
    public PickList(OrderBatch batch);
    public void email(string recipient);
    public void print();
}

Just because something is related to a class doesn't mean its implementation belongs in that class. Your OrderBatch might have the single responsibility of storing all the data for a batch of orders (and maintaining its integrity). Other classes can do stuff with with order batch.

Answer 2

An order batch is a real thing. Its responsibility is keeping a bunch of order items together. That makes it a fairly complex entity that requires a lot of management tasks. So be it. As long as they make sense in the order batch context, that is just fine.

What is typically named a God class is a class that has hetrogenious behavior and/or data, not so much one that just happens to have a great number of methods and/or properties.

[edit]

Looking at your example though, some things do come to mind. It does not look right to have Email... and Print... methods in there. First, picklist is a class in its own right that may have a constructor that takes a collection of items which may be obtained from the order batch. Then, printing or emailing it is a separate concern. You may need a PickListFormatter class that prepares picklists for presentation purposes.

OrderBatch may be a bad name, perhaps it really is a ProductionBatch. Ask what the purpose of the batch class is (what do the orders have in common?) and have that expressed in the name. This will define the responsibility. Is it a ShippingBatch? OrderBatch says nothing more than "bunch of orders" leaving you guessing for what purpose, making it impossible to judge if a particular method belongs or not. First you need to define the responsibility, once that is clear, picking the right behavior is not so hard any more.

Answer 3

"Identifying Objects in the problem/business domain" is a requirements analysis task, which should not be confused with detailed, technical class design. It is one way to use classes as a rough ordering tool for "user stories" or requirements, but they should not be the final classes one wants to create during design and implementation (at least not if one prefers to get some maintainable piece of software).

The classes implemented in real code, however, should follow the SRP. They will be more fine-grained than the classes one uses during requirements analysis and typically on a different level of abstraction.

Answer 4

What would happen if we had an object class with alot of different behaviors. How would that not violate the Single Responsibilty Principle?

Most likely.

Let's speak more in terms of the domain itself. While I'm not an expert at order batching and pick list ordering:

An Order Batch is a collection of orders, not necessarily from the same customer, but in the same phase of fulfillment.

An order batch may go thru a number of different transitions. The order batch may be initially unordered; later a pick list ordering is established based on some fulfillment criteria.

And if it is a violation, how would I split it?

You might consider these separate abstractions: (1) the unordered batch of orders, (2) the ordered pick list based on (3) fulfillment criteria that provides a grouping of line items across orders.

The fulfillment criteria is more likely related to the structuring of the warehouse; a different warehouse might provide a different fulfillment criteria, which would have the effect of ordering the pick list differently. Thus, the fulfillment criteria is a separate responsibility.

Emailing and printing are probably out of scope for any of these. Each merely need to be traversable/navigable so that you can enumerate the underlying elements by other components that handle email and printing concerns.

Creating the order batch is also an independent responsibility, as we can imagine that the choosing the orders that are actually batched together can yield an efficiency that is either more or less optimal.

Is this a violation of the SRP?

If we were to attempt all of these abstractions in a single class that would indeed be a violation of SRP.

However, SRP doesn't mean separate everything into tiny abstractions that then have to be stitched together by the consumer or are awkward and unnatural to use. We have to balance SRP with quality abstraction. SRP tends to argue for separation, whereas quality abstraction tends to argue for bundling. Sometimes, if we can't find a balance between separation and bundling, it is because we have more independent concepts that need to be teased out into their own abstraction.

In this particular case, we need separate concepts for an order batch itself vs. the strategies for batching orders together, and for ordering pick lists, which are related more to their environment. The order batch may go thru states and transitions, which itself is sufficient responsibility (and may use several classes) without also realizing the ordering/grouping strategies.

Answer 5

I always map the responsibility of modules to the layer of abstraction that it is part of.https://dzone.com/articles/single-responsibility. A class and its methods both have responsibilities, but they operate at different levels.

I think it is important to maintain both "low representational gap" as well as SRP. I would accomplish this by delegation/composition/inheritance. i.e. the interface of OrderBatch is maintained, but the implementation is delegated.