What would happen if we had an object class with alot of different behaviors. How would that not violate the Single Responsibilty Principle?
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.