In postul precedent am descutat despre o problema care poate sa apara cand expunem intr-un API metode virtuale, care sunt apoi suprascrise de catre un alt dezvoltator. Iar o versiune ulterioara a API schimba comportamentul aplicatiei in asa fel incat suntem obligati sa schimbam codul care foloseste API expus.
Mai jos gasiti o posibila solutie la aceasta problema.
O alta varianta este ca metode DoActionCore sa fie declarata ca si abstracta, in cazul in care vrem sa obligam dezvoltatorul sa defineasca un comportament custom.
Mai jos gasiti o posibila solutie la aceasta problema.
O solutie de acest gen o sa functioneze, doar daca cel care expune API o sa o foloseasca de la prima versiune.public abstract class FooBase
{
private void DoAction(){// Custom code that can be executed by our method.DoActionCore();// More custom code that can be executed by our method.}public virtual void DoActionCore(){// Some action}
}
public class MyCustomFoo : FooBase
{public override void DoActionCore(){// My custom code of MyCustomFoo that will be// executed by DoAction method from base class.}
}
O alta varianta este ca metode DoActionCore sa fie declarata ca si abstracta, in cazul in care vrem sa obligam dezvoltatorul sa defineasca un comportament custom.
Solutia asta are si un nume - template method pattern (http://en.wikipedia.org/wiki/Template_method_pattern).
ReplyDeleteE ok ca si metoda de a permite customizarea behaviour-ului unei clase cat timp nu apar ierarhii de clase pe mai mult de 2 nivele, si cat timp nu apare necesitatea ca pentru o singura metoda din clasa de baza sa se ofere mai multe puncte de extensie - in ambele cazuri template method (foarte folosit cu ceva ani in urma) duce la cod greu de inteles si de intretinut.
Mersi Tudor ca acum pot sa pun titlu la un sablon pe care il cunosteam si foloseam ;)
Delete:) e doar o conventie - si eu il foloseam cu 10 ani in urma si nu stiam cum l-au botezat..
Delete