Blog - Chetan Patil

January 30, 2017September 9, 2018

Check number is Fibonacci numbers or not

A simple way is to generate Fibonacci numbers until the generated number is greater than or equal to ‘n’. Following is an interesting property about Fibonacci numbers that can also be used to check if a given number is Fibonacci or not.
A number is Fibonacci if and only if one or both of ( 5*n2 + 4 ) or ( 5*n2 – 4 ) is a perfect square (Source: Wiki). Following is a simple program based on this concept.

<?php

$count = 0 ;
$f1 = 0;
$f2 = 1;

echo '---- Correct Fibonacci series ----<br/>';
echo $f1." , ";
echo $f2." , ";

while ($count < 50 ) 
{
 $f3 = $f2 + $f1 ;
   echo $f3." , ";
 $f1 = $f2 ;
 $f2 = $f3 ;
 $count = $count + 1;
}

echo '<br/>---- Fibonacci series array with some wrong elements ----';
$aFabonacySeriesArray = [ 0 , 1 , 1 , 2 , 3 , 4,  5 , 6 , 8 , 12 , 13 , 16 , 21 , 34 , 55 , 89 , 144 , 233 , 377 , 610 , 987 , 1597 , 2584 , 4181 , 6765 , 10946 , 17711 , 28657 , 46368 , 75025 , 121393 , 196418 , 317811 , 514229 , 832040 , 1346269 , 2178309 , 3524578 , 5702887 , 9227465 , 14930352 , 24157817 , 39088169 , 63245986 , 102334155 , 165580141 , 267914296 , 433494437 , 701408733 , 1134903170 , 1836311903 , 2971215073 , 4807526976 , 7778742049 , 12586269025 , 20365011074 ];
var_dump($aFabonacySeriesArray);

// Loop each number and check given number is Fibonacci or not
foreach ( $aFabonacySeriesArray as $key => $value ) {
    echo isFibonacci( $value ) ? ( $value . ' - is a Fibonacci Number <br/>' ) : ( $value . ' - is a not Fibonacci Number <br/>' );
}

function isPerfectSquare( $x )
{
    return gmp_perfect_square( ( string ) $x );
}
 
// Returns true if n is a Fibinacci Number, else false
function isFibonacci( $n )
{
    // n is Fibinacci if one of 5 * $n * $n + 4 or 5 * $n * $n - 4 or both
    // is a perferct square
    return isPerfectSquare( 5 * $n * $n + 4 ) || isPerfectSquare( 5 * $n * $n - 4 );
}
?>

<?php

$count = 0 ;

$f1 = 0;

$f2 = 1;

echo '---- Correct Fibonacci series ----<br/>';

echo $f1." , ";

echo $f2." , ";

while ($count < 50 )

{

$f3 = $f2 + $f1 ;

echo $f3." , ";

$f1 = $f2 ;

$f2 = $f3 ;

$count = $count + 1;

}

echo '<br/>---- Fibonacci series array with some wrong elements ----';

$aFabonacySeriesArray = [ 0 , 1 , 1 , 2 , 3 , 4, 5 , 6 , 8 , 12 , 13 , 16 , 21 , 34 , 55 , 89 , 144 , 233 , 377 , 610 , 987 , 1597 , 2584 , 4181 , 6765 , 10946 , 17711 , 28657 , 46368 , 75025 , 121393 , 196418 , 317811 , 514229 , 832040 , 1346269 , 2178309 , 3524578 , 5702887 , 9227465 , 14930352 , 24157817 , 39088169 , 63245986 , 102334155 , 165580141 , 267914296 , 433494437 , 701408733 , 1134903170 , 1836311903 , 2971215073 , 4807526976 , 7778742049 , 12586269025 , 20365011074 ];

var_dump($aFabonacySeriesArray);

// Loop each number and check given number is Fibonacci or not

foreach ( $aFabonacySeriesArray as $key => $value ) {

echo isFibonacci( $value ) ? ( $value . ' - is a Fibonacci Number <br/>' ) : ( $value . ' - is a not Fibonacci Number <br/>' );

}

function isPerfectSquare( $x )

{

return gmp_perfect_square( ( string ) $x );

}

// Returns true if n is a Fibinacci Number, else false

function isFibonacci( $n )

{

// n is Fibinacci if one of 5 * $n * $n + 4 or 5 * $n * $n - 4 or both

// is a perferct square

return isPerfectSquare( 5 * $n * $n + 4 ) || isPerfectSquare( 5 * $n * $n - 4 );

}

Output –

—- Correct Fibonacci series —-
0 , 1 , 1 , 2 , 3 , 5 , 8 , 13 , 21 , 34 , 55 , 89 , 144 , 233 , 377 , 610 , 987 , 1597 , 2584 , 4181 , 6765 , 10946 , 17711 , 28657 , 46368 , 75025 , 121393 , 196418 , 317811 , 514229 , 832040 , 1346269 , 2178309 , 3524578 , 5702887 , 9227465 , 14930352 , 24157817 , 39088169 , 63245986 , 102334155 , 165580141 , 267914296 , 433494437 , 701408733 , 1134903170 , 1836311903 , 2971215073 , 4807526976 , 7778742049 , 12586269025 , 20365011074 ,
—- Fibonacci series array with some wrong elements —-

array (size=56) 0 => int 0 1 => int 1 2 => int 1 3 => int 2 4 => int 3 5 => int 4 6 => int 5 7 => int 6 8 => int 8 9 => int 12 10 => int 13 11 => int 16 12 => int 21 13 => int 34 14 => int 55 15 => int 89 16 => int 144 17 => int 233 18 => int 377 19 => int 610 20 => int 987 21 => int 1597 22 => int 2584 23 => int 4181 24 => int 6765 25 => int 10946 26 => int 17711 27 => int 28657

0 – is a Fibonacci Number
1 – is a Fibonacci Number
1 – is a Fibonacci Number
2 – is a Fibonacci Number
3 – is a Fibonacci Number
4 – is a not Fibonacci Number
5 – is a Fibonacci Number
6 – is a not Fibonacci Number
8 – is a Fibonacci Number
12 – is a not Fibonacci Number
13 – is a Fibonacci Number
16 – is a not Fibonacci Number
21 – is a Fibonacci Number
34 – is a Fibonacci Number
55 – is a Fibonacci Number
89 – is a Fibonacci Number
144 – is a Fibonacci Number
233 – is a Fibonacci Number
377 – is a Fibonacci Number
610 – is a Fibonacci Number
987 – is a Fibonacci Number
1597 – is a Fibonacci Number
2584 – is a Fibonacci Number
4181 – is a Fibonacci Number
6765 – is a Fibonacci Number
10946 – is a Fibonacci Number
17711 – is a Fibonacci Number
28657 – is a Fibonacci Number

January 20, 2017September 9, 2018

Constructor

What does Constructor mean?

A constructor is a special method of a class or structure in OOP that initializes an object of that type. A constructor is an instance method that usually has the same name as the class, and can be used to set the values of the members of an object, either to default or to user-defined values.

Constructors are not called explicitly and are invoked only once during their lifetime. In the case of a hierarchy of classes where a derived class inherits from a parent class, the execution sequence of the constructor is a call to the constructor of the parent class first and then that of the derived class.

Constructors cannot be inherited.

A constructor can be declared using any of the access modifiers. It is mandatory to have a constructor with the right access modifier. However, the compiler supplies a default if an access modifier is not defined in the class. If a constructor is declared as private, the class cannot be created or derived and hence cannot be instantiated. Such a constructor, however, can be overloaded with different sets of parameters.

Constructor design:

When using derived class constructors, the parent class constructor should be passed the correct parameters.

Better code maintainability comes from having the initialization and other related logic in one main constructor and cross-calling this constructor from other overloaded constructors.
Logic involving specific operations that need to be executed at a particular event in an application – such as opening a database connection – should not be written in a constructor.
Because a constructor cannot return a value to the calling code, it is a good practice to throw an exception when a failure is encountered.

July 12, 2016September 9, 2018

Dependency injection in PHP

Dependency Injection is a software design pattern that allows avoiding hard-coding dependencies and makes possible to change the dependencies both at runtime and compile time.

By using Dependency Injection we can write more maintainable, testable, and modular code. All projects have dependencies. The larger the project the more dependencies is it bound to have; now having a great number of dependencies is nothing bad by itself however how those dependencies are managed and maintained is.

Dependency Injection is not a new pattern and it has been commonly used on many languages like Java, but this pattern is somewhat new in the PHP world and it’s gaining traction quickly thanks for frameworks like laravel

Let’s exemplify these concepts by creating a pair of classes first without dependency injection and then rewriting the code to use the dependency injection pattern; since I’m primarily a Magento developer I’ll be really original (wink, wink) and create a Product and a StockItem class.

<?php

class StockItem {

  private $quantity;
  private $status;

  public function __construct($quantity, $status){
   $this->quantity = $quantity;
   $this->status   = $status;
  }

  public function getQuantity(){
   return $this->quantity;
  }

  public function getStatus(){
   return $this->status;
  }

}

<?php

class StockItem {

private $quantity;

private $status;

public function __construct($quantity, $status){

$this->quantity = $quantity;

$this->status = $status;

}

public function getQuantity(){

return $this->quantity;

}

public function getStatus(){

return $this->status;

}

<?php
class Product {
  private $stockItem;
  private $sku;

  public function __construct($sku, $stockQuantity, $stockStatus){
    $this->stockItem  = new StockItem($stockQuantity, $stockStatus);
    $this->sku        = $sku;
  }

  public function getStockItem(){
    return $this->stockItem;
  }

  public function getSku(){
    return $this->sku;
  }
}

<?php

class Product {

private $stockItem;

private $sku;

public function __construct($sku, $stockQuantity, $stockStatus){

$this->stockItem = new StockItem($stockQuantity, $stockStatus);

$this->sku = $sku;

}

public function getStockItem(){

return $this->stockItem;

}

public function getSku(){

return $this->sku;

}

At first glance the code looks pretty normal and it’s what many PHP developers would call good code, however if we take a closer look at it using the S.O.L.I.D principle we can see that the code actually has many problems:

The StockItem is tightly coupled with the Product class, and while this might not look bad on this particular example. Let’s imagine that we made a change to the StockItem class to include a new parameter, we would then have to modify every single class where the StockItem object was created.
The Product class knows too much, in this case the stock status and quantity, let’s say that our application can handle inventories from multiple sources and stores but for the same product. With that in mind it would be in our best interest to make the Product class know less about its inventory.
We just made our life harder when it comes to unit testing the code. Since we are instantiating the stockItem inside the constructor it would be impossible to unit test the Product class without also testing the StockItem class.

Let’s Inject something!

In the other hand by using dependency injection we can correct most of these problems, let’s take at the same code but using dependency injection:

<?php

class StockItem {

  private $quantity;
  private $status;

  public function __construct($quantity, $status){
   $this->quantity = $quantity;
   $this->status   = $status;
  }

  public function getQuantity(){
   return $this->quantity;
  }

  public function getStatus(){
   return $this->status;
  }

}

<?php

class StockItem {

private $quantity;

private $status;

public function __construct($quantity, $status){

$this->quantity = $quantity;

$this->status = $status;

}

public function getQuantity(){

return $this->quantity;

}

public function getStatus(){

return $this->status;

}

<?php

class Product {
  private $stockItem;
  private $sku;

  public function __construct($sku, StockItem $stockItem){
    $this->stockItem  = $stockItem;
    $this->sku        = $sku;
  }

  public function getStockItem(){
    return $this->stockItem;
  }

  public function getSku(){
    return $this->sku;
  }
}

<?php

class Product {

private $stockItem;

private $sku;

public function __construct($sku, StockItem $stockItem){

$this->stockItem = $stockItem;

$this->sku = $sku;

}

public function getStockItem(){

return $this->stockItem;

}

public function getSku(){

return $this->sku;

}

Constructor Injection

By using dependency injection we have more maintainable code, in the previous example we are using a type of dependency injection normally referred as Constructor Injection. By doing a simple change we can reduce the level of complexity of our code and improve the overall quality; not to mention that now we can easily run unit tests.

Constructor injection is by far the most common method used and there are several advantages by using this particular type of injection:

If the dependency is required by the class and cannot work without it, by using constructor injection we guarantee that the required dependencies are present.
Since the constructor is only ever called when instantiating our object we can be sure that the dependency can’t be changed or altered during the object lifetime.

These two points make Constructor Injection extremely useful, however there is also a few drawbacks that make it unsuitable for all scenarios:

Since all dependencies are required, it’s not suitable when optional dependencies are needed.
While using class inheritance trying to extend and override the constructor becomes difficult.

Setter Injection

Another common type of dependency injection is called setter injection and the same code as above would look something like this:

<?php

class StockItem {

  private $quantity;
  private $status;

  public function __construct($quantity, $status){
   $this->quantity = $quantity;
   $this->status   = $status;
  }

  public function getQuantity(){
   return $this->quantity;
  }

  public function getStatus(){
   return $this->status;
  }

}

<?php

class StockItem {

private $quantity;

private $status;

public function __construct($quantity, $status){

$this->quantity = $quantity;

$this->status = $status;

}

public function getQuantity(){

return $this->quantity;

}

public function getStatus(){

return $this->status;

}

<?php

class Product {
  private $stockItem;
  private $sku;

  public function __construct($sku){
    $this->sku        = $sku;
  }

  public function getStockItem(){
    return $this->stockItem;
  }

  public function getSku(){
    return $this->sku;
  }

  public function setStockItem(StockItem $stockItem){
    $this->stockItem = $stockItem;
  }
}

<?php

class Product {

private $stockItem;

private $sku;

public function __construct($sku){

$this->sku = $sku;

}

public function getStockItem(){

return $this->stockItem;

}

public function getSku(){

return $this->sku;

}

public function setStockItem(StockItem $stockItem){

$this->stockItem = $stockItem;

}

As we can see, with Setter Injection the dependencies are provided to our class after it has been instantiated using setter methods. Setter Injection has a few advantages:

Allows for optional dependencies and the class can be created with default values.
Adding new dependencies is as easy as adding a new setter method and it won’t break any existing code.

Setter Injection might be more suitable for situations where more flexibility is required.

July 8, 2016September 9, 2018

Differences between abstract class and interface in PHP

In abstract classes this is not necessary that every method should be abstract. But in interface every method is abstract.
Multiple and multilevel both type of inheritance is possible in interface. But single and multilevel inheritance is possible in abstract classes.
Method of php interface must be public only. Method in abstract class in php could be public or protected both.
In abstract class you can define as well as declare methods. But in interface you can only defined your methods.

July 8, 2016May 30, 2018

Traits in PHP

One of the problems of PHP as a programming language is the fact that you can only have single inheritance. This means a class can only inherit from one other class.

However, a lot of the time it would be beneficial to inherit from multiple classes. For example, it might be desirable to inherit methods from a couple of different classes in order to prevent code duplication.

This problem can lead to class that has a long family history of inheritance which often does not make sense.

In PHP 5.4 a new feature of the language was added known as Traits. A Trait is kind of like a Mixin in that it allows you to mix Trait classes into an existing class. This means you can reduce code duplication and get the benefits whilst avoiding the problems of multiple inheritance.

PHP Traits?

A Trait is simply a group of methods that you want include within another class. A Trait, like an abstract class, cannot be instantiated on it’s own.

An example of a Trait could be:

trait Sharable {
 
  public function share($item)
  {
    return 'share this item';
  }
 
}

trait Sharable {

public function share($item)

{

return 'share this item';

}

You could then include this Trait within other classes like this:

class Post {

  use Sharable;

}

class Comment {

  use Sharable;

}

class Post {

use Sharable;

}

class Comment {

use Sharable;

}

Now if you were to create new objects out of these classes you would find that they both have the share() method available:

$post = new Post;
echo $post->share(''); // 'share this item'

$comment = new Comment;
echo $comment->share(''); // 'share this item'

				1
2
3
4
5

						$post = new Post;
echo $post->share(''); // 'share this item'
 
$comment = new Comment;
echo $comment->share(''); // 'share this item'

How do Traits work?

As you can see from the example above, both the Post and the Comment objects have the share() method available despite not having that method defined.

A Trait is basically just a way to “copy and paste” code during run time.

This means the Trait is copied in to the Post and Comment classes so when you instantiate a new instance, the share() method code will be available.

How are Traits different to Abstract classes?

A Trait is different to an Abstract class (What are Abstract classes?) because they do not rely on inheritance.

Imagine if the Post and the Comment class had to inherit from a Social class. We are most likely going to want to do more than just share posts and comments on social media websites, so we’ll probably end up with a complicated inheritance tree like this:

class Validate extends Cache {}
class Social extends Validate {}
class Post extends Social {}

class Validate extends Cache {}

class Social extends Validate {}

class Post extends Social {}

This complicated inheritance is pretty nasty, but it also adds complication when a simpler object does not have a similar inheritance structure. For example, if we had a Message object that shouldn’t allow social sharing, then this object would require a slightly different inheritance structure.

How are Traits different to Interfaces?

Traits kind of look a lot like Interfaces. Both Traits and interfaces are usually simple, concise and not much use without an actual implemented class. However the difference between the two is important.

An interface is a contract that says “this object is able to do this thing”, whereas a Trait is giving the object the ability to do the thing.

For example:

// Interface
interface Sociable {

  public function like();
  public function share();

}

// Trait
trait Sharable {

  public function share($item)
  {
    // share this item
  }

}

// Class
class Post implements Sociable {

  use Sharable;

  public function like()
  {
    //
  }

}

// Interface

interface Sociable {

public function like();

public function share();

}

// Trait

trait Sharable {

public function share($item)

{

// share this item

}

// Class

class Post implements Sociable {

use Sharable;

public function like()

{

}

In this example we have a Sociable interface that states that the Post object is able to like() and share().

The Sharable Trait implements the share() method and the like() method is implemented in the Post class.

So as you can see we could type hint the Post object to see if it is sociable (it implements the Sociable interface), whilst the Trait defines a reusable method that we can then mix in to other similar classes:

$post = new Post;

if($post instanceOf Sociable)
{
  $post->share('hello world');
}

				
					
				1
2
3
4
5
6

						$post = new Post;
 
if($post instanceOf Sociable)
{
  $post->share('hello world');
}

					

			

Benefits of Traits?

The benefit of using Traits is that you reduce code duplication whilst preventing complicated class inheritance that might not make sense within the context of your application.

This allows you to define simple Traits that are clear and concise and then mix in that functionality where appropriate.

Drawbacks of Traits?

However with that being said, there are possible drawbacks when using Traits too.

Traits make it very easy to write bloated classes that have too much responsibility. A Trait is essentially a way to “copy and paste” code between classes. By having a way to very simply add another group of methods to a class, it’s very easy to diverge from the single responsibility principle.

Other drawbacks to using Traits are not being able to see all the methods of a class when looking at the source code as well as method conflicts or duplication of logic.

I think Traits, when used correctly, are a fantastic tool to have at our disposal. However, Traits can also be crutch for lazy programming. It’s very easy to just add a Trait to solve your immediate problem. Often composition is the better approach over inheritance or using a Trait.

What are typical situations for using Traits?

So what would be a typical situation when using a Trait would be a good idea?

Well, I think Traits are an excellent way to reuse a chunk of code between a set of similar classes that should not inherit from the same abstract class.

Using the social application from earlier, imagine we had objects for Post, Photo, Note, Message and Link. For the most part, these objects are fairly interchangeable within our system as they are typically created and interacted with between users.

However, Post, Photo, Note and Link are all objects that are publicly shareable between users, whereas Message objects are private messages that are not made public.