Reading resources about object oriented programming the logic is to avoid
public methods as much as possible. The public methods will provide the
interface through which other objects will interact with our class.
This interface should be as simple as possible and the details of the implementation should be hidden inside private methods.
My question arises because of the non testable character of private methods.
The code should be testable right? I am not sure how these two approaches are integrated in a consistent development approach...
You should be able to test a class by testing its public methods. If that is not enough coverage and there is still lots of functionality in private or protected methods then maybe they should be in a separate class.
Some people say that if you use TTD then all methods should start public and that private methods should only be re-factored from already working and tested code.
You can also test private or protected if you have to using mocks.
A brief description of public, private and protected:
public: Accessible by other classes
private: Not accessible by other classes
protected: Not accessible by other classes but accessible by derived classes
Reading resources about object oriented programming the logic is to avoid public methods as much as possible.
That's not entirely true. If a method is only used within your class and it's not part of the interface exposed by your class then of course that method needs to be private (or protected if you intend to extend your class). Public methods are part of the interface, they are methods that are designed to be called by other classes. You should not force yourself to limit the use of public methods. If a class needs a lot of public methods then it should have them. Just don't expose the inner mechanics of a class to the outside world and you will be fine.
About testing, private and protected methods can be tested with the use of Reflection. Reflection makes it possible to change the accessor of a method from private to public for testing purposes and much more. Read more about reflection here
Related
I have read in laravel's facade documentation the following sentence:
Typically, it would not be possible to mock or stub a truly static
class method.
1) question 1: I'm trying to understand facade in laravel. As I guess, it's implemented because if we have classes, and they have big namespaces and big names and every time we want to use this class and we don't want to use new keyword and use statements, we use the facade which is an easier code and readable. I also think that laravel implemented facades because they wanted to write non-static functions in their classes so that they could be tested. After all of this, we use facades like static classes (because of readability and not using new and use), but in reality, it makes new instances.
Am I right?
2) If the above is right, can you provide me an example why it's not possible to test a static method as laravel docs said?
A facade does not solve the big namespaces problem you mentioned. Big namespaces are solved using aliases. You can declare them in your config/app.php and internally Laravel will use class_alias when you call them. This is how e.g. \Cache or \DB work.
A facade is basically a proxy class to a singleton object instance of another class (the facade itself ensures the instance is a singleton).
Typically to register a singleton in Laravel you:
Add app()->singleton(ABC::class) in your service provider
Access it via app()->make(ABC::class)->...
A facade basically takes care of that for you if you haven't already registered that class as a singleton.
Basically a facade is a way to proxy that singleton instance of another class.
Also it's generally not possible to mock or stub static methods however if you are using facades you can do \ABCFacade::swap($mockObject) and therefore your facades can be mocked.
It is also false that you cannot test a static method. You can absolutely test a static method. For example:
public testStaticMethod() {
$this->assertEquals(1, ABC::method()); // We tested a static method against a desired behaviour
}
What you usually can't do is mock a static method. Here's how you would typically mock something with PHPUnit:
public testWithDependency() {
$dependency = $this->getMockBuilder(Dependency::class)->getMock();
$dependency->expects($this->once())->method('dependantMethod')->willReturn(true);
$objectToTest = new ABC($dependency); //We're passing a fake dependency which behaves in an ideal way
$this->assertEquals(1, $objectToTest->methodToTest()); //Any calls to the dependency will call mock methods and not real ones
}
The problem arises when trying to mock a static method. As you can see mocking creates mock instances of a certain type. It can't mock the static members of that type because the mock object itself is not actually of that type.
However as I just found out the statement that it's not possible to mock or stub a static method is not entirely true. There's the AspectMock you can mock static methods or helper methods. This seems to work by intercepting all function calls via a custom autoloader.
This being said, just because you can doesn't mean it's good practice to use static methods, there's other issues to consider like e.g. you normally can't have static interfaces in most programming languages or you normally can't override static methods in most programming languages. Note the "in most programming languages" part here. In PHP it's entirely possible to override static methods with late static binding but that means you need to make a conscious decision about this when implementing the static method.
Another disadvantage is that a class of statics can't implement an interface because interfaces apply to object behaviours and not the static behaviour. Therefore you can't swap out one interface for another if you are using statics which is a major disadvantage.
In general the aversion to static methods is not because of testability but because if you are coding in OOP you are really limited if you are using statics.
Hopefully this will help clear up some confusion.
I have a class that is containing 10 methods. I always need to use one of those methods. Now I want to know, which approach is better?
class cls{
public function func1(){}
public function func2(){}
.
.
public function func10(){}
}
$obj = new cls;
$data = $obj->func3(); // it is random, it can be anything (func1, or func9 or ...)
OR
class cls{
public static function func1(){}
public static function func2(){}
.
.
public static function func10(){}
}
cls::func3(); // it is random, it can be anything (func1, or func9 or ...)
It is an interesting subject. I'm gonna give you a design oriented answer.
In my opinion, you should never use a static class/function in a good OOP architecture.
When you use static, this is to call a function without an instance of the class. The main reason is often to represent a service class which should not be instantiated many times.
I will give you 3 solutions (from the worst to the best) to achieve that:
Static
A static class (with only static functions) prevent you from using many OOP features like inheritance, interface implementation. If you really think of what is a static function, it is a function namespaced by the name of its class. You already have namespaces in PHP, so why add another layer?
Another big disadvantage is that you cannot define clear dependencies with your static class and the classes using it which is a bad thing for maintenability and scalability of your application.
Singleton
A singleton is a way to force a class to have only one instance:
<?php
class Singleton {
// Unique instance.
private static $instance = null;
// Private constructor prevent you from instancing the class with "new".
private function __construct() {
}
// Method to get the unique instance.
public static function getInstance() {
// Create the instance if it does not exist.
if (!isset(self::$instance)) {
self::$instance = new Singleton();
}
// Return the unique instance.
return self::$instance;
}
}
It is a better way because you can use inheritance, interfaces and your method will be called on an instanciated object. This means you can define contracts and use low coupling with the classes using it. However some people consider the singleton as an anti pattern especially because if you want to have 2 or more instances of your class with different input properties (like the classic example of the connection to 2 different databases) you cannot without a big refactoring of all your code using the singleton.
Service
A service is an instance of a standard class. It is a way to rationalize your code. This kind of architecture is called SOA (service oriented architecture). I give you an example:
If you want to add a method to sell a product in a store to a consumer and you have classes Product, Store and Consumer. Where should you instantiate this method? I can guarantee that if you think it is more logical in one of these three class today it could be anything else tomorrow. This leads to lots of duplications and a difficulty to find where is the code you are looking for. Instead, you can use a service class like a SaleHandler for example which will know how to manipulate your data classes.
It is a good idea to use a framework helping you to inject them into each others (dependency injection) in order to use them at their full potential. In the PHP community, you have a nice example of implementation of this in Symfony for instance.
To sum up:
If you do not have a framework, singletons are certainly an option even if I personally prefer a simple file where I make manual dependency injection.
If you have a framework, use its dependency injection feature to do that kind of thing.
You should not use static method (in OOP). If you need a static method in one of your class, this means you can create a new singleton/service containing this method and inject it to the instance of classes needing it.
The answer depends on what those methods do. If you're using them to mutate the state of the object at hand, you need to use the instance method calls. If they're independent functionality, then you can use the static versions, but then I'd question why they're part of a class at all.
So, there is a very basic difference in static methods.
To use static functions, you don't need to initialise the class as an object. For example, Math.pow(), here .pow() (in Java; but the explanation still holds) is a static method.
The general rule is to make the helper methods static.
So, for example, if you have a Math class, you wouldn't want to fill the garbage collector with classes which just help other, more important, classes.
You can use it as dynamic initializers, if you please!
Let's say you have a class RSAEncryptionHelper, now you can generally initialize it without any parameters and this will generate an object with a key size of (say) 512 bits; but you also have an overloaded object constructor which gets all of the properties from other classes:
$a = new RSAEncryptionHelper::fromPrimeSet(...);
Within a PHP class you can use class/methods/attributes: Abstract, Static, Private, Public, etc ...
The best way is to know how to mix them all within a class depending on the need, I will give you a basic example:
Within the Person class, you have private and public methods, but you have a method called "get_nationality" so this is a function that you need somewhere else but you do not have the Person class installed yet, so this method you put it as STATIC in this way you can invoke the "get_nationality" method without installing any Person class, this makes your business model more optimal and in turn now resources in the CPU.
Static functions are also very useful but
I usually make traits when I have to create functions that are independently related to a class.
I don't know if this approach is better or not but most times I found it useful.
Just sharing my approach here so that I can learn more about its pros and cons.
You can think a factory. You will give some materials, it will give you same output. Then you should use static function.
class ProductDetails
{
public static function getRow($id, PDO $pdo): SingleProduct
{
// this function will return an Object.
}
}
I am not defining the Object here. Just where you need a Single Product you can simply do that ProductDetails::getRow(10, $pdo);
It is OK to have methods depend one on each other inside a class, methods that are encapsulated together? Does this affect unit testing? or the term Unit is addressing to the whole class and not to the class own methods.
It is OK to do something like this:
<?php
class foo {
protected $baz;
protected $bar;
private function checkBaz($baz) {
// do some checking
}
private function checkBar($bar) {
// do some checking
}
public function setBaz($baz) {
if($this->checkBaz($baz)){
$this->baz = $baz;
}
}
public function setBar($bar) {
if($this->checkBar($bar)){
$this->bar = $bar;
}
}
}
I'm thinking if I want to use a bound method from this class to another class I have to rewrite the method a little bit, I was wandering if it is overhead to make methods somehow encapsulated like inserting functionality in to method parameters, Is this a common practice in OOP or should I stick to the thinking that a class is an encapsulation of high cohesion method and properties and see it like a whole reusable and testing Unit.
Yes, calling methods internally in a class is absolutely fine. In fact, it's encouraged. The mere presence of protected and private methods should be a dead giveaway. You can only call those from within the class, from somewhere that needs to be triggered by a public method, so yes, your example if perfectly in line with how those methods are supposed to be used.
The only thing that matters in general and in terms of unit testing is how the object as a whole behaves. Its public components are important, that's what other code interacts with and it's what other code observes. Whatever kinds of internal calls your object/class makes is perfectly up to its own discretion. If it helps your class structure to put certain code in separate methods and hide them from the outside world, so be it.
Yes, performing method calls like this is perfectly fine. They're marked as private so they remain encapsulated within your class and unexposed to the outside world.
If these method calls started to cause the class/object to deviate its main purpose, breaking single responsibility principle, then it would be worth looking at breaking the class into finer units and injecting this new dependency via dependency injection. An example of this would be if the checkBaz method was performing a database look-up.
In terms of unit testing, what you really want to do is program to an interface not implementation by creating an interface for your foo class and implementing it. This means whenever you program to it you're programming to a contract - allowing you to easily mock your IFoo implementation.
eg:
class Foo implements IFoo {
}
Your interface will look like this:
interface IFoo
{
public function setBaz($baz)
public function setBar($bar)
}
I would also recommend following the PEAR coding standard and make your class names uppercase first. Though if this is a decision made by you or your team then that's entirely your call.
There's nothing wrong with non-public methods. In fact, a class should only export the bare minimum of public methods to allow other classes to make use of its services. The more external classes know about the inner workings of your class, the more difficult it is to make changes to the inner workings of your class without upsetting external dependencies.
The non-public methods should be tested by being called indirectly. There should be a circumstance under which every method gets called eventually, even if it's through indirect calling (public method calls private method, etc). If a method is never executed in a unit test then that's a good indicator that it is in fact dead code and can be removed from the class altogether.
You can in theory directly test the protected methods of a class by subclassing it and elevating the protected methods to public, but that's not recommended because it exposes internal workings of your class and you don't really want to do that.
when I look through GitHub most projects define methods in the interface this way:
interface ExampleInterface
{
function getId();
}
my question now is why it is bad style to define the method visability in the Interface:
interface ExampleInterface
{
public function getId();
}
It makes the interface more strict but isn't that whats an interface used for?
what is the point of a private function in an interface? declaring public is redundant.
from TFM:
All methods declared in an interface must be public, this is the nature of an interface.
http://php.net/manual/en/language.oop5.interfaces.php
It is because an interface is a promise you give to the outside world of certain functionality. In your above example, whenever a class implements an interface, it is guaranteeing that the class will provide a method called getId to the outside world, irrespective of how it is implemented.
Hence, if you make a private promise, it is irrelevant as no one cares if there is a private method with some functionality, it is anyways not accessible by anyone else.
On the other hand, all methods in an interface are essentially public (since they are nothing but promises to the outside world) and hence you explicitly mentioning it as public is redundant.
Interfaces can only contain public methods, so the public is a bit redundant.
An interface can only have public members so there's no need to declare it. And these functions are meant to be inherited. Therefore; All methods declared in an interface must be public, that is its nature..
I can understand that private cannot work but protected as well?
I understand it is a "promise" to the outside world but if something implements an interface that method will stay protected therefore the same "promise" was still kept. It stated that there is function a, function b and also protected function c so from that we derive if I am not extending/implementing this then I can not have access to function c. Because it works the same when you read classes.
#AlphaMale Ok so what is the point of an interface then? It is used to create a "recipe" for a class right? So when you use it practically in code it will only be to implement and force methods. This becomes handy if methods are needed for your code to work and you don't want to force it to a specific class.
Lets say I have a to create Mailers, but I have to major processes where mails are needed but mailers will use different ways of constructing these mails. Now There needs to be a base send function that takes a message(any type) and a email address, but since the classes are in an open environment then it will be dangerous to leave this send function public and therefore we need it as a protected method. Now in the two Processes there are multiple mailers but each process shares the same way of constructing the method, so there is 2 abstract classes but now due to limited interfaces you now have to declare a third abstract class to contain this protected send function so that it can be extended as well otherwise you will have the same protected send function. If a new developer works on a completely new process and looks at the interface then the send function will never be forced. If we say it was possible to declare protected in an interface then outside if you check if something is an interface it will work the same as a class, you still can't access the the protected functions.
Private makes sense because then only the interface will know about these values and since an interface can't do anything this will be pointless.
I'm trying to work out how to best complete my design work on my classes.
my situation.
i have an order abstract class that contains order methods and information that are required for 2 children classes
order_Outbound
and order_inbound
each child class requires 2 static public method called create and get
but from what i have read about php 5.3 you cant have abstract static methods ???
so my thought was to have an interface Order_Interface which takes over that role but how do i implement it. do i still implement it in the parent class
in which case the parent abstract class still requires me to create a get and create method within the abstract class. or do i implement it in the children and extend from the abstract class???
ALSO!!!
both the outbound and inbound children require a create static method but require different parameters to be passed
can i in the interface have public static function create()
and in its implementation within order_outbound declare it public static function create($address, $reference, $orderID)
In most languages, including PHP, you cannot require a class to implement static methods.
This means neither class inheritance, nor interfaces, will allow you to require all implementors define a static method. This is probably because these features are designed to support polymorphism rather than type definition. In the case of static methods you'll never have an object to resolve the type from, so would have to do ClassName::Method explicitly, so the theory is you wouldn't gain anything from polymorphism.
As such, I see three solutions
Declaring the static methods in each class (after all, you are never going to
If you want a method to create instances of your class, but don't want to require an instance to call this method, you could create "Builder" classes to serve this purpose (e.g. OrderBuilder), such that you instantiate an OrderBuilder and call the Create method on this object instead to get Order instances.
(Recommended) Why aren't you simply using the Order constructor?
Update
After the comment from #hvertous, I decided to test this out. Using 3v4l we can see that abstract public static method:
Works for versions 5 > 5.1.6
Doesn't work for 5.2 > 5.6.38
Works for 7.0.0 > 7.3.1
Which confirms that it was removed in PHP 5.2, but if you are using PHP 7+ you can once again use abstract static methods.
Original answer
Yes, abstract static methods were removed in PHP 5.2. Apparently they were an oversight. See Why does PHP 5.2+ disallow abstract static class methods?.
However, you can have static methods in an interface, see this comment on php.net.
The problem you face is that you want your implementations to have different function signatures, which means that you probably shouldn't be using inheritance to solve your problem.
PHP 7.4+ allows to require a static method in an interface:
interface StaticInterface {
public static function interfaceMethod();
}
class MyProvider implements StaticInterface {
//public static function interfaceMethod() {}
}
Fatal error without the method: https://3v4l.org/YbA4u
No errors when implementing the method: https://3v4l.org/QNRJB