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

Posted on 2007-10-02
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 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
    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.
    LVL 7

    Accepted Solution

    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

    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

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    How to improve team productivity

    Quip adds documents, spreadsheets, and tasklists to your Slack experience
    - Elevate ideas to Quip docs
    - Share Quip docs in Slack
    - Get notified of changes to your docs
    - Available on iOS/Android/Desktop/Web
    - Online/Offline

    The Fluent Interface Design Pattern You can use the Fluent Interface ( design pattern to make your PHP code easier to read and maintain.  "Fluent Interface" is an object-oriented design pattern that r…
    Exception Handling is in the core of any application that is able to dignify its name. In this article, I'll guide you through the process of writing a DRY (Don't Repeat Yourself) Exception Handling mechanism, using Aspect Oriented Programming.
    Need more eyes on your posted question? Go ahead and follow the quick steps in this video to learn how to Request Attention to your question. *Log into your Experts Exchange account *Find the question you want to Request Attention for *Go to the e…
    Here's a very brief overview of the methods PRTG Network Monitor ( offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…

    737 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

    Need Help in Real-Time?

    Connect with top rated Experts

    19 Experts available now in Live!

    Get 1:1 Help Now