Abstraction is your friend: A software design is a complex thing, especially, if you do not use abstraction to good effect. The design should be done at various levels of abstraction. At higher levels, you visualize the system as a small number of big components while abstracting away the details of what is inside each component. Once you have a good definition of what each of those components represent and how they interact with each other, you can move to the next lower level of abstraction. That is, you take each one of those components and design it using a small number of smaller components. This can go on until you reach a lower level of abstraction that is concrete enough to transform to an implementation.
Separate different concerns
For example, parsing (and things related to the "parsing" concern) should be done by the parser component, and everything that has to do with sorting should be done by the sorter component.
Don't talk to strangers (aka law of Demeter)
Keep unrelated things independent of each other. For example, if the parser component can function without any knowledge of the sorter component, then the sorter is a stranger to the parser. That means the parser should not have any reference to the sorter (E.g., can you compile the parser without compiling the sorter?)
A classic example where this principle applies is when choosing between a central controller model and chain of controllers model. The former lets you keep strangers as strangers, while the latter forces strangers to talk to each other.
TODO: elaborate on the above, with an example
Along the same vein, minimize communication between components. Avoid cyclic dependencies (e.g., A calls B, B calls C and C calls A)
Don't tell your secrets
A component should as little as possible about itself. This is also known as information hiding. For example, other components that interact with your component should not know how your component store certain data and they should not be allowed to manipulate those data directly.