Short, but concise and inspired talk about aspect-oriented programming. Brilliant insights into building scalable, and future-proof application domain boundaries using BEAR.Sunday to generate HATEOAS compliant API’s; with realtime synthesised documentation.
“The talk is centred around the idea of community. PHP has one of the best communities we know. Its people are passionate, enthusiastic, loyal, and smart. But, there is a problem. We somehow feel, whether we like to admit it or not, that for our community, our language, to be great, it must be at the cost of another community or another language. Perhaps a framework we don?t like so much, or another language that thinks is better than ours. We make little remarks, or take cheap shots at the ?competition?. But it doesn’t have to be that way. When I started coding all those years ago I had no idea there would be hoards of other developers waiting to share ideas and pass on the knowledge - all for the love of code. Which is the real reason we?re all here. We all love code. The talk will revolve around the idea that all software-based communities have so much in common. That we all have a common purpose - to share and promote the thing we love. But we can promote our community without detracting from others. Using the philosophy of "Think Win-Win” from The 7 Habits of Highly Effective People, I will discuss how shift in attitude can means we can all promote our beloved language and promote others too, and still win."
Your code should deal directly with the Injector as little as possible. Instead, you want to bootstrap your application by injecting one root object. The container can further inject dependencies into the root object’s dependencies, and so on recursively. In the end, your application should ideally have one class (if that many) which knows about the Injector, and every other class should expect to have dependencies injected.
For extensions, I encourage you to copy entire class and modify it. Does this sound too wild ? Here are my thoughts.
Suppose we make a protected method for future modification. Is this a symptom of violating SRP? If we separate the “extensible concern” and “core concern”, why not separate them as extensible dependency objects in order to conserve SRP?
Yes we loose the some convenience. But a true DI system give us more flexibility with ease. Inherited modification needs hard coded relationships. The modifications and the original class become tightly coupled. In other words, modification of dependency object injection can be done by context and we can then draw the object graph more freely.
Just conform to DIP, seriously….
An ‘unchangeable public methods and no protected method policy’ encourage us to use the final keyword. This helps makes the class stable and closed. The @api annotation may then be needed less.
先日米国ワシントンで開催されたPHP Worldのアンソニー・フェラーラさんによる基調講演PHP7 and Beyond: The Future of PHP をYouTubeでみました。
その中で「Victory for PHP」と話します。「PHPはプログラムを始めたばかりの初心者から、大企業のシニアまで、最小のWebサイトから世界最大級のサイトまで全ての人に力を与える。
I thought it was about something completely different. It introduced Aspect oriented programming (something I had only seen in other languages, and had not considered using with PHP). The speaker was from Japan and had a guy interpreting for him at times. It should have been a disaster, but was not. It was interesting.
I spoke a lot to Akihito Koriyama, who wrote a framework called BEAR, which breaks a lot of the principles that the popular frameworks follow. It does this in a way that improves the object-oriented structure of the application from more traditional architectures.