[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now


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

Posted on 2007-10-02
Medium Priority
Last Modified: 2013-11-12
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.


Question by:jazz__man
LVL 23

Assisted Solution

by:Ashish Patel
Ashish Patel earned 660 total points
ID: 19996826
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.

Accepted Solution

joesthebighmoe earned 680 total points
ID: 19998755
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.
LVL 21

Assisted Solution

surajguptha earned 660 total points
ID: 20008618
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

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Dependencies in Software Design In software development, the idea of dependencies (http://en.wikipedia.org/wiki/Coupling_%28computer_programming%29) is an issue of some importance. This article seeks to explain what dependencies are and where they …
"Disruption" is the most feared word for C-level executives these days. They agonize over their industry being disturbed by another player - most likely by startups.
Exchange organizations may use the Journaling Agent of the Transport Service to archive messages going through Exchange. However, if the Transport Service is integrated with some email content management application (such as an anti-spam), the admin…
When cloud platforms entered the scene, users and companies jumped on board to take advantage of the many benefits, like the ability to work and connect with company information from various locations. What many didn't foresee was the increased risk…
Suggested Courses
Course of the Month19 days, 18 hours left to enroll

873 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question