These Are Not Facades

[pmjones]

Hey man -- these aren't "facades." They're static proxies to service locators. I'm guessing you got the term from Laravel; they misuse the term.

[joshmanders]

Actually you're using the term correctly, just like in Laravel. You're not using the Facade Pattern therefore @pmjones is wrong.

[pmjones]

No, he's using the "Proxy Pattern" which is the correct naming convention.

[itsgoingd]

Hey, I follow the whole conversation about Laravel facades, so I understand your point very well and I agree that naming this Laravel feature "facades" is a bit unfortunate.

Naming stuff is hard, the name is already well estabilished in the Laravel community and changing it might be actually more confusing (to Laravel users) then arguably using the wrong word. This library is built directly on top of Laravel implementation so it would be illogical to call it differently here.

I personally don't see this as such a big problem though, as I think that this library has many of the characteristics of the facade pattern (as described on wiki).

I'll leave this open for now, I might reconsider renaming if more people find the name confusing and I will watch the development in Laravel.

[noodlehaus]

wow. you just got spotted by the php mafia.

[pmjones]

@itsgoingd Dude, it's your project, you get to do what you want, but it's not a facade pattern, and calling it "facade" really is a problem with the naming. Call it proxy, call it locator, call it surrogate, call it "george" -- those would not be referencing the wrong pattern. But "facade" is not the right thing to reference here. If you care at all about naming things properly, I beseech you with my deepest humility to consider it.

[GRAgmLauncher]

I have to agree with pmjones on this one. Developers need to be able to communicate with each other using a commonly understood language.

A facade takes is something that takes a complex, multi-step operation, and simplifies it.

Logging a user in involves several steps:

1. Hashing the password
2. Querying the database by the provided identifier
3. Comparing the hashed password with the one from the database
4. Throwing an error/exception if they don't match or if the user can't be found
5. Or updating the session if they do match
6. Checking if the password needs rehashing
7. If it does, rehash it
8. Save the re-hashed password in the database.

Providing a LoginHandler that wraps all of that behind a single function call ( login() ) is what makes it a facade. Simplifies a complex process (or hides a complex process behind a simplified API, to be more accurate).

THAT is what a facade is. Thus anything which is not that, must be called something different.

And this is not being anal or weird. It boils down to using accurate language - something everyone should do, but especially people who are building things that other people use.

@killswitch I think it's pretty obvious that calling these Facades implies the Facade Pattern. You're getting into semantics by trying to split hairs between Facades and the Facade Pattern.

[joshmanders]

@GRAgmLauncher False. These Facades and Laravel Facades do not claim to be Facade Pattern @pmjones disputes it despite being completely wrong. These and Laravel Facades follow what is the definition of a Facade:

Which the word comes from the French word façade, which in turn comes from the Italian
facciata, from faccia meaning face, ultimately from post-classical Latin facia. The earliest
usage recorded by the Oxford English Dictionary is 1656

Which obviously predates programming patterns

As you can see by that definition, these Facades are EXACTLY what a Facade is.

[pmjones]

@killswitch: If you were writing a novel, or doing an architectural plan for a physical building, using the word "facade" in that way would be perfectly reasonable. But we are building software. In a software context, "facade" carries the GoF Patterns connotation, not the English prose connotation.

[GRAgmLauncher]

@killswitch. Not false. You're using the word facade in the wrong context. This is English; the same word can have several different meanings depending on the context. The context matters. You are not using the correct context here.

You claim, that laravel and this project do not claim that they are using the Facade Pattern. That would hold weight if the word facade existed within multiple contexts of software architecture the way factory does. But it does not.

Moreover, what would you call a class that implements the Facade Pattern? You would inevitably have to refer to it as a "facade", as referring to that class as "a facade pattern" is awkward and not really correct. Therefore, facade implicitly means "facade pattern".

Further, it's a bit odd that you're using building architecture as the most relevant example of the context of a facade, rather than the most immediately relevant context of facade in this discussion, which is software architecture. You went out of your way to find the least least relevant context of "facade".

[joshmanders]

If true definition doesn't matter unless context is added, then we're all doing MVC wrong. Now shut the hell up and build something instead of arguing over stupid definitions.

[pmjones]

The definition of MVC in a web context is a long-standing argument, one that has plenty of merit. But if what you're saying is that "MVC is wrong so every other term is wrong too" then that's pretty weak.

Oh, and I am trying to build something: programmers who have a better understanding of their profession.

[joshmanders]

I am a programmer who has a great understanding of my profession, you're arguing about things you have no proof of. You say you don't want to be fixing Taylor's mess of Facades yet, before I came to Laravel I never really knew what a Facade was, I looked it up, I found out. I do not confuse the two.

[pmjones]

Good for you!

[thejw23]

I think that @pmjones is doing quite good job in the field of building a better understanding of programmers profession. His posts about Facades are right, @brandonsavage also pointed it out quite well: "When we use these terms incorrectly, we not only devalue them, we confuse developers". It really matters to call things with proper terms.

[GRAgmLauncher]

Haha awesome way to convince people you're right: "Shut the hell up and build something".

Sheesh...

[noodlehaus]

If we're going to argue about context, and how it should be respected when using terms correctly, then by right every term we use in programming that is based on words that existed before programming, are all incorrectly used and should be dropped since we are not using them in their original context.

software engineering is a sub context, derived from the original english language context, so laravel or this project using the term facade in a new sub context is just as right or just as wrong as the GoF in coining terms in a new sub context.

let's please drop this useless pissing contest. it's not productive, and just a big waste of time.

[pmjones]

I agree -- it's useless for Laravel to continue using the term improperly.

[GRAgmLauncher]

@noodlehaus

It's not about original vs new context, or parent vs sub-context, or original vs derivative context. It's about THIS context only. In THIS context (software engineering), facade means facade pattern. It doesn't matter what it means outside of THIS context. It is its own meaning in this context, and a different meaning in a different context. It is not any more complicated than that.

This particular use of the word facade does NOT constitute a new context. The context is the same: software engineering. Quite literally, there are two different definitions of the word facade that are crammed together in the same context. This is why it's a problem - it makes for poor, inconsistent communication and interpretation.

[silentworks]

Guys take your argument somewhere else, @pmjones thanks for dropping by and letting the author of this library know about the misuse of the name. Now can everyone else carry on their argument on another discussion board or something. It is now down to the author of this library to decide if he want to change the name or not.

[pmjones]

Yes, I agree with @silentworks -- as I said earlier, it's entirely up to @itsgoingd to choose his own path.

[dillinghamio]

The second I saw "Facade" in the title and skimmed the features of this repo I thought to myself "Ahhh so that's what facades do." Being that I am infact a novice programmer, and have stumbled past the phrase "Facade Pattern" a time or two in researching code, it was misleading and without this thread I would of continued being mislead by my own lack of thorough research. One day I may be a purist like those against this, but for the time being Im just happy to have this awesome little library in a moment of need. Thanks for taking time out of your day and coding it. Cheers.

[pmjones]

Hey, I agree it's nice to provide functionality. But it needs to use the right name, and unfortunately Facade is the wrong name here.

[joshmanders]

[boussou]

This is very true. Software Design Patterns and their naming are meant to ease understanding of "best solutions to common problems". They are a toolbox, like UML. Ie if you say to a software architect that a particular class uses a singleton, or a Visitor, you don't have to show the code. He knows.

To understand "Visitor", you never open a dictionary (weird idea anyway).

A proxy should be called a proxy, it is a pattern used elsewhere like in Java (RMI), Corba, etc. You should also read about "dynamic proxy" for your knowledge.

In the end, maybe PHP magic methods are just plain evil from an OO perspective.

(troll fed).