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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
dhint4
  • 151
  • 1
  • 1
  • 6
  • 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
  • Amon, that was exactly my first thought as well! Why use a source control system that locks the entire file completely? – dhint4 Mar 29 '15 at 17:17
  • 1
    Because code merges are a pain in the ass, that's why. – Robert Harvey Mar 29 '15 at 17:41
  • @RobertHarvey: Are code merges a bigger pain in the butt than needless delays caused by a restriction in source control mitigated by merging? I understand some VCS's handle merges better than others but merging should be a skill every development team cultivates. No one works in a silo. – Greg Burghardt Mar 29 '15 at 19:39
  • @GregBurghardt: See Doc Brown's answer below. While merging is a nice capability to have, it's hard to imagine multiple developers having to work on the same class at the same time on a regular basis, in a well-architected application. – Robert Harvey Mar 29 '15 at 19:55
  • Merging non-conflicting changes in the same file is a task that pretty much any VCS does well (using heuristics). The question is simply based on outdated assumptions. There is no problem here. – usr Mar 29 '15 at 21:09

1 Answers1

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.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565