Do we need design patterns in our web applications? (Question for good system architect - Not too brain taxing)

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 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.


Who is Participating?
Wow, that's a huge question. ;-) Here's a few comments...
Your application is a business application first. Please remember that. The part that makes it "web" is the fact that you are going to provide a user interface to your application via a browser. On a "monster application" it is even more crucial that you make sure to separate the two in your mind and design. Make sense?
Second, the hierarchy of Megastore.Branch.Employee.Cashier.Contract is all data related, but not necessarily behaviorally related. OO design is based on behavior of your objects, not the hierarchy of data. Almost every business system is made up of one or more huge hierarchies. If we loaded up our objects in this way we would almost be pulling our entire database into memory. That's a wrong turn and I am quite sure you will not find that advice in a single OO design book.
"Given the "academic rules" of OOP my classes are surely violating rules such as low-coupling and High cohesion" - I have not seen any of your class designs so I wouldn't know. At a minimum you want to keep your classes cohesive by making their focus singular. Pick an object and tell me its purpose in terms of the business. Then look at the methods of that object, are they all directly related to that purpose? That would be cohesion.
As an experienced OO developer I would tell you (and many might disagree and that's OK) that programming to interfaces is not a basic or academic rule of OO. It has its benefits in many situations but is often something we refactor towards as opposed to starting off with. If you want to think academic, think abstraction, think cohesion, think encapsulation, think data-hiding, in other words you can almost wrap all this up as thinking about a separation of concerns.
Also I think it can be helpful, speaking of a separation of concerns, to think about the parts of your design that handle maintenance (maybe adding a Cashier) and those that handle the business (maybe scheduling delivery of stock conflicts) as separtae beasts.
I hope I helped more than confused.
Ashish PatelCommented:
Rather than creating all individual methods for returning all branches (50 branches or so) create a generic method where in you can pass some id and get the branches. OOPs is a wide concept and the topic which you have given is also wider in concept of discussion. But as from programmer's view we always design patterns in such a way that it reduces the code and sometimes its good not to follow all rules of academic studies.
If you are going to design a part of a bigger system, i would suggest that such a contract is well understood by the other systems and all the systems understand the contracts.

>>Instead of designing one big monolithic class for a Branch, is to break the Branch into many smaller entities.

>> Or you could just follow creating the classes the way the database is organized. Are you looking at using DLINQ/ nHibernate?

>> Even though you are designing the entire sub system, i dont think there would be a need to represent the whole sytem. it will usually be a emplyee lookup or Bill generation where the entities are smaller in scope
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.