What made to introduce Factory and Abstarct Factory design patterns

I have gone through the design patterns, came to know that a design pattern is a solution for a problem in software development. but here am not getting the real time problem which made to use Factory and Abstract factory design patterns as a solution. I have searched in google in all possible ways but am not satisfied/convinced with problem they described. Can you please help me out here

Best practice to implement callback function when DOM element rendered

While I do not know if it is possible, I am always facing such scenario for a long time without a "good" way to solve it. No matter what technology I used: ASP.NET, plaing JS/JQuery, any other web development frameworks...

The scenario is that:

How to set up a callback function which will fired when some specific DOM element is rendered?

For example, I have a button on the document, and I would like to simulate a click when this button is rendered.

This is the method I used the most for now (probably the dumbest method):

$(function(){
   setTimeout( simulate the click, or w/e I want,  100);
});

I would set the delay by trial & error. While it works most of the time, if I keep refreshing the page, there will be one or two times it fails, as the button is not yet rendered on the document after 100ms. Also I suspect this method is machine / browser dependent...in short it is bad.

I believe there is some much better way to achieve the same effect, what is the common / best practice out there to handle such scneario?

Does facade class in facade pattern need to be static?

I was going through MSDN article about facade pattern. http://ift.tt/22yThvY

I couldnt find reason why they made facade a static class ? Why they used static variables to hold instances of subsystem classes ? Why did they use static methods ? I would like to know reason behind it.

Below is the static code section from that article. Full code can be found inside article.

public static class Facade 
{
     static SubsystemA a = new SubsystemA(  );
     static SubsystemB b = new SubsystemB(  );
     static SubsystemC c = new SubsystemC(  );

     public static void Operation1(  ) {
       Console.WriteLine("Operation 1\n" +
           a.A1(  ) +
           a.A2(  ) +
           b.B1(  ));
    }

     public static void Operation2(  ) {
       Console.WriteLine("Operation 2\n" +
           b.B1(  ) +
           c.C1(  ));
     }
   }

private static throughout code

I am on a new project, and the legacy java code is filled with Classes that are using private static methods, and often classes are implementing public static. its very hard to follow.

for example

public Car {
    private static checkGas(){ 
       ..
    }

   public static startCar(){
..
}
}

Is there some design pattern I never heard of that would make this applicable?

I've always used public static methods , on "helper" classes that do not need Util.caculate(..) , and the above "Car" example I wouldn't have a private static , or a public static...just private, public methods

Dispose pattern usage

I read these articles on Dispose Pattern and Dispose Implementation. My question is when calling the virtual dispose(bool) method from the finalizer, why we only pass false to the method and release unmanaged resource? If we pass true, what will it break?

Also even we have implemented the IDisposble interface, it still relies on the developer to either wrap the code in the using block or to call Dispose() explicitly, in order for the Dispose() method to be invoked. What is the addon of the IDisposble interface, if the developer is not careful enough?

Factory with switch over enum that instantiates templates

I have the following hierarchy pattern in various places in the codebase:

enum DerivedType {
    A, B, C };

class Base {
public:
  static Base* Create(DerivedType t);
};

template <DerivedType T>
class Derived : public Base {
};

The Create method returns a new object of class Derived<A>, Derived<B>, or Derived<C>, depending on its argument:

Base* Base::Create(DerivedType t) {
  switch (t) {
  case A: return new Derived<A>;
  case B: return new Derived<B>;
  case C: return new Derived<C>;
  default: return NULL;
  }
}

The problem is that there are many such Base -> Derived hierarchies, with essentially the same implementation of Create() copy-pasted all over the place. Is there an elegant, yet easy-to-understand way to avoid duplication here?

Where to place functions for add, delete in composite pattern

Composite pattern is useful for handling part-whole hierarchies. It has an interface for the Component. Leaf and Composite both provide implementation for the Component interface.

What should be the implementation for Add(Component c), Remove(Component c) and GetChild(int position) methods in Leaf class ?

I can have methods do nothing, or throw an exception like : OperationNotSuportedByLeafException. But Doing this will break the Liskov substitution principle. What is the best way to handle these methods ?