First, thanks for taking the time to read this question. I realise this is a very big subject but the following are questions that every developer has faced and had to make decisions on.
Lets say I am developing a monster commercial web app for a chain of large food retailer outlets to manage everything from staff, accounts, stock, deliveries etc etc....
Lets call the store...Megastore!
Lets say I am working on a part of the system that manages Cashier employees and their contract of employment details. So the heirarchy is as follows...........
Now if you think about it, the above the megastore class could be huge if say there were a method for returning each branch if say there were (50 branches or so). In addition, the branch class could also be very large if there were methods for returning every type of employee. etc etc..
Given the "academic rules" of OOP my classes are surely violating rules such as low-coupling and High cohesion, program to Interfaces, not implementations etc..But is this really such a bad thing?
So how should we be structuring a major system like this? In the above example, please bear in mind that the current system deign is not polymorphic....is this bad? This leads me on to the next issue as to whether design patterns ...or should I say...the underlying principles of design patterns are good.
I would be very grateful for as much constructive advice, help or opinions on this issue.