Items in category refactoring

Dependency Injection via Factory

Refactoring
Dependency Injection via Factory
Photo by Julien Tromeur on Pixabay

You know, when coupling is not loose, components depend too much on each other. It makes your entire architecture fragile and immobile. You can check how loose the coupling is by making a unit test for a component. If you have no problem substituting dependencies by e.g. mock objects then everything is ok. Let take a model class. It depends on DB connection, here \Lib\Db\Adapter\Interfaceinstance. We cannot just create DB adapter instance within model constructor, because it depends on configuration data which doesn’t belong to the model.

Design by Contract and JS

Refactoring
Design by Contract and JS
Photo by mohamed Hassan on Pixabay

Related articles: Prototypal Inheritance in JavaScript for Modulesand Scalable JavaScript Application DesignDesign by contract (DbC) is an approach in application design, which originally came from Eiffel, but now widely used on different languages (particularly in Java). In real world one party (supplier) makes an offer for an agreement (business contract) and another one (client) accepts. The same way can be described relations between objects in software engineering. As a declared agreement is accepted by the client object, the last one is expected to keep its rules.

Flyweight pattern using Mixins

Refactoring
Flyweight pattern using Mixins
Photo by PublicDomainPictures on Pixabay

In my previous article among other patters I was telling about Flyweight. That is about the objects designed so to minimize memory use by sharing as much data as possible with other similar objects. You can find plenty of Flyweight implementation examples in Internet, though it will be mostly variations of Multiton, a collection (map) keeping only instance per every identical object. And I decided to follow that unwritten rule as it seems to be the simplest way to show the idea.

Design Patterns by PHP and JavaScript examples

Refactoring
Design Patterns by PHP and JavaScript examples
Photo by Free-Photos on Pixabay

After having your project fully tested, deployed and running, it seems the application architecture is pretty good enough. All the requirements met and everybody is happy. But then as it happens, the requirements change and you, all of sudden, find yourself in the time of troubles. It comes out that some modules easier to hack than to modify. Change of other ones brings endless changes in a cascade of dependent modules.

Aspect-oriented Software Development and PHP

Refactoring
Aspect-oriented Software Development and PHP
Photo by Arek Socha on Pixabay

Introduction Object oriented approach has been popular for a number of years. Its advantages can hardly be visible within short-term projects, yet any major long-term one simply cannot do without it. Object-oriented programming languages provide the tools necessary to present business logic in a demonstrable form. Today UML Class diagram (http://en.wikipedia.org/wiki/Unified_Modeling_Language) does suggest itself even on the stage of developing the system logic. Demonstrable business logic makes it easier for new participants to join in, helps to save time for those developers that come back into the project at later stages.