3

I came across this article: http://didawiki.cli.di.unipi.it/lib/exe/fetch.php/magistraleinformatica/tdp/dp-l10a-facade2014.pdf

At the end, it has a question asking:

One common problem experienced by software development teams who use the Façade Pattern occurs when the Façade class is used to represent the entire system on which the team is working. A team of 20-30 people sends every method call to the system through the Façade, with each team member making several changes to the system per day.

Because of the heavy dependency on the Façade class, however, the team’s schedule is frequently delayed because the Façade class is often locked by a particular developer for quite some time.

Discuss how this problem might be overcome without sacrificing the use of the Façade Pattern.

Can somebody explain to me how we might be able to solve this problem while still using the Facade Pattern? A clear answer doesn't pop directly into my mind.

  • 5
    Use several smaller Façades instead of one large one. – Robert Harvey Mar 29 '15 at 17:07
  • Robert, thanks for your comment. Can you explain why using several smaller Facades is a good approach? – dhint4 Mar 29 '15 at 17:10
  • Because locking a smaller facade won't lock the entire large one, leaving the other smaller facades available for editing. – Robert Harvey Mar 29 '15 at 17:10
  • 4
    Even better idea: Don't use a revision control system that requires you to lock the files you're currently editing. With a modern DVCS such as Git, edits in different parts of the same file don't conflict with each other, and can be seamlessly merged together. – amon Mar 29 '15 at 17:14
  • 1
    Because code merges are a pain in the ass, that's why. – Robert Harvey Mar 29 '15 at 17:41
12

If you design a system where 20-30 people all have to edit the same class of your codebase on a daily basis, I would say you will have a pretty big organizational issue and a pretty big architectural issue as well with your system. If such a class is a facade or something else is irrelevant.

To solve these issues, I would start with splitting the teams to a smaller size, with at maximum 5 to 6 developers per teams, and each team only responsible for a part of the codebase. Assumed each team manages some components, with well-defined interfaces between the components, your "facade" will be in one of those components, so you have in fact reduced the number of people which can get a conflict to 5-6.

If those 5 to 6 people still have to edit that class each day, then there is still something wrong with the responsibilities of that class. It is probably a god class, a well-known anti pattern, and the solution to deal with that is exactly what Robert Harvey wrote in the comments: split the class up into smaller ones.

Note that just using a class by lots of people does not lock it, that is pretty nonsense (even if you use a version control system from "the dark ages" like PVCS). Only editing a class simultanously by two people may lead to a conflict, which can be solved by the help of any decent version control system.

  • Great scott! Use git, Marty! – gdbj Mar 27 '17 at 17:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.