The Clean Code Talks - "Global State and Singletons"

By: GoogleTechTalks

904   24   139065

Uploaded on 11/18/2008

Google Tech Talks
November 13, 2008


The Clean Code Talk Series

Speaker: Misko Hevery

Comments (7):

By anonymous    2017-09-20

Instead of that dreadful abomination, you should learn how to utilize spl_autoload_register():

spl_autoload_register( function( $classname ){

    $filename = 'inc/classes/' . $classname . '.class.php';

    if ( !file_exists( $filename) ){
        throw new Exception("Could not load class '$classname'.". 
                            "File '$filename' was not found !");

    require $filename;


And you should register the autoloader in your index.php or bootstrap.php file, and do it only once per loader (this ability lets you define multiple loaders, but that's used, when you have third party library, which has own autoloader .. like in case of SwiftMailer).

P.S. please learn to use prepared statements with MySQLi or PDO.


Since you are just now learning OOP, here are few things, which you might find useful:



Original Thread

By anonymous    2017-09-20

Since you request a way to mock a DataContext I assume that you really want to do some unit tests and not integration tests.

Well, I will tell you how to accomplish this, but first I would like to encourage you to read the following links, they are all about writing clean testable code.

And check the links from this response:

Watch the clean code talks from Misko Hevery (given to the Google people)

One thing that I used to repeat to myself and to my fellows at work, is that anyone can write a unit test, because they are silly easy to write. So a simple test is essentially all about making some comparisons and throw exceptions if the results fails, anyone can do that. Of course, there are hundreds of frameworks to help us write those tests in an elegant way. But the real deal, and the real effort shroud be put on learn how to write clean testable code

Even if you hire Misko Hevery to help you write tests, he will have a real hard time writing them if your code is not test-friendly.

Now the way to mock a DataContext objects is: do not do it

Instead wrap the calls using a custom interface instead:

public interface IMyDataContextCalls
    void Save();
    IEnumerable<Product> GetOrders();
// this will be your DataContext wrapper
// this wll act as your domain repository
public class MyDataContextCalls : IMyDataContextCalls
    public MyDataContextCalls(DataClasses1DataContext context)
        this.Context = context;

    public void Save()

    public IEnumerable<Product> GetOrders()
        // place here your query logic
        return this.Context.Products.AsEnumerable();

    private DataClasses1DataContext Context { get; set; }


// this will be your domain object
// this object will call your repository wrapping the DataContext
public class MyCommand
    private IMyDataContextCalls myDataContext;
    public MyCommand(IMyDataContextCalls myDataContext)
        this.myDataContext = myDataContext;

    public bool myDomainRule = true;

    // assume this will be the SUT (Subject Under Test)
    public void Save()
        // some business logic
        // this logic will be tested
        if (this.myDomainRule == true)
            // handle your domain validation  errors
            throw new InvalidOperationException();

public class MyTestClass
    public void MyTestMethod()
        // in this test your mission is to test the logic inside the 
        // MyCommand.Save method
        // create the mock, you could use a framework to auto mock it
        // or create one manually
        // manual example:
        var m = new MyCommand(new MyFakeDataContextFake());

        m.Invoking(x => x.Save())
            //add here more asserts, maybe asserting that the internal
            // state of your domain object was changed
            // your focus is to test the logic of the domain object

        //auto mock example:
        var fix = new Fixture().Customize(new AutoMoqCustomization());
        var sut = fix.CreateAnonymous<MyCommand>();
        sut.myDomainRule = false;

        sut.Invoking(x => x.Save())

    public class MyFakeDataContextFake : IMyDataContextCalls
        public void Save()
            // do nothing, since you do not care in the logic of this method,
            // remember your goal is to test the domain object logic

        public IEnumerable<Product> GetOrders()
            // we do not care on this right now because we are testing only the save method

            throw new NotImplementedException();


  • When you declare your IMyDataContextCalls interface you are actually abstracting the use of a DataContext, therefore this interface should contain only POCO objects (most of the time), if you follow this approach your interfaces will be decoupled from any undesired dependency.

  • In the specific MyDataContextCalls implementation, you are explicitly using a DataClasses1DataContext context, but you are free to change the implementation at any time and that won't affect your external code, and that's because you are always working with the IMyDataContextCalls interface instead. So at any time you could change for example this implementation for another one using the wonderful NHibernate =) or the poor ef or a mock one

  • At last, but not least. please double check my code, and you will notice that there are no new operators in the domain objects. This is a rule of dumb when writing test friendly code: decouple the responsibility of creating objects outside of your domain objects

I personally use three frameworks on every project and on every test I write, I really recommend them:

For example, in the code above, I showed you how to write a manual fake for your repository, but that clearly is something we do not want to do in a real project, imagine the number of objects you would have to code in order to write your tests.

Instead use the power of AutoFixture combined with Moq:

This line: var m = new MyCommand(new MyFakeDataContextFake());

Will become:

        var fixture = new Fixture().Customize(new AutoMoqCustomization());
        var sut = fixture.CreateAnonymous<MyCommand>();

And that's it, this code will automatically create mocks for all the objects needed in the constructor of MyCommand.

Original Thread

By anonymous    2017-09-20

I know the "mydata" pointer will be just available on this particular cpp file

That's false. mydata will be a global variable. If you have another mydata global variable in another .cpp, they can collide (or at least they will violate the one definition rule).

Use unnamed namespaces for mydata:

namespace {
    myData* mydata = nullptr;

This way, mydata won't be accessible to other translation units.

But: global variables are not recommended. Don't use them. They almost always have alternatives.

There is a technical reason, which related to C++ only: static initialization order fiasco

And there are design decisions behind:

Original Thread

By anonymous    2017-11-06

I am learning the popular MVC and trying to implement it in PHP. I am designing a framework with a pure OOP fashion (though I am not expert in PHP's OOP ability. I only have moderate knowledge about it). An example implementation of this framework as shown in the following figure. enter image description here

In this framework I added a Data Access Layer, DAL, (a class to deal with the connection, executing query and transport to and from the database) to abstract the physical database from the rest of the system to easy change of the data source. If a system is only bind to one database of one particular type, this layer is expected to presented in the system using only one object with one connection to the database. And this object will be a dependency for all the Data Mapper objects (i.e., User mapper, Product Mapper).

I am looking for your comments on where to initiate the DAL object in the system. I can create the object in the front controller (index.php) and transport all the way to Data Mapper objects. But it is an anti-pattern according to Here and Here. Even for the same reason, we cannot initiate the DAL object within the factories (Factories can be separated in multiple classes for handling complexities as per Clean code approach ). I cannot use Singleton as that is also going to create lots of problem according to this. So, in your opinion, what is the best practice and place where I can initiate this object and pass it to Data Mapper objects?

N.B.: I disregard the View Logic here as my concern do not have any relation with Views.

Original Thread

Recommended Books

    Popular Videos 293

    Submit Your Video

    If you have some great dev videos to share, please fill out this form.