Introduction to Object Oriented Programming Concepts (OOP) and More

By Nirosh, 25 an 2!"" #$%& ('55 (otes)

" 2 ' # 5

o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o

#$%&)5 * '55 (otes "' remo(ed + #$&#, ,a "$!& -./ "$ Introduction 2$ Bac0ground '$ Prere1uisites #$ 2he Main Content #$"$ 3hat is 4o5t6are 7rchitecture. #$2$ 3hy 7rchitecture is important. #$'$ 3hat is OOP. #$#$ 3hat is an Object. #$5$ 3hat is a C8ass. #$9$ :o6 to identi5y and design a C8ass. #$&$ 3hat is ;ncapsu8ation (or in5ormation hiding). #$%$ 3hat is 7ssociation. #$<$ 3hat is the di55erence bet6een 7ssociation, 7ggregation and Composition. #$"!$ 3hat is 7bstraction and =enera8i>ation. #$""$ 3hat is an 7bstract c8ass. #$"2$ 3hat is an Inter5ace. #$"'$ 3hat is the di55erence bet6een a C8ass and an Inter5ace. #$"#$ 3hat is the di55erence bet6een an Inter5ace and an 7bstract c8ass. #$"5$ 3hat is Imp8icit and ;?p8icit Inter5ace Imp8ementations. #$"9$ 3hat is Inheritance. #$"&$ 3hat is Po8ymorphism. #$"%$ 3hat is Method O(er8oading. #$"<$ 3hat is Operator o(er8oading. #$2!$ 3hat is Method O(erriding. #$2"$ 3hat is a @se case. #$22$ 3hat is a C8ass Aiagram. #$2'$ 3hat is a Pac0age Aiagram. #$2#$ 3hat is a 4e1uence Aiagram. #$25$ 3hat is t6o*tier architecture. #$29$ 3hat is three*tier architecture. #$2&$ 3hat is MBC architecture. #$2%$ 3hat is 4O7. #$2<$ 3hat is the Aata 7ccess Cayer. #$'!$ 3hat is the Business Cogic Cayer. #$'"$ 3hat is =ang o5 Dour (=oD) Aesign Patterns. #$'2$ 3hat is the di55erence bet6een 7bstract Dactory and Bui8der design patterns. 5$ 3hat is the Conc8usion.

9$ 3hat I Ee5erred. &$ :istory

1. Introduction
I ha(e noticed an increase in the number o5 artic8es pub8ished in the 7rchitect category in code*project during the 8ast 5e6 months$ 2he number o5 readers 5or most o5 these artic8es is a8so high, though the ratings 5or the artic8es are not$ 2his indicates that readers are interested in reading artic8es on 7rchitecture, but the 1ua8ity does not match their e?pectations$ 2his artic8e is a constructi(e attempt to group) de5ine) e?p8ain a88 introductory concepts o5 so5t6are architecture 5or 6e88 seasoned de(e8opers 6ho are 8oo0ing to ta0e their ne?t step as system architects$ One day I read an artic8e that said that the richest 2 percent o6n ha85 the 6or8dFs 6ea8th$ It a8so said that the richest " percent o5 adu8ts o6ned #! percent o5 g8oba8 assets in the year 2!!!$ 7nd 5urther, that the richest "! percent o5 adu8ts accounted 5or %5 percent o5 the 6or8dFs tota8 6ea8th$ 4o there is an unba8anced distribution o5 6ea8th in the physica8 6or8d$ :a(e you e(er thought o5 an unba8anced distribution o5 0no68edge in the so5t6are 6or8d. 7ccording to my (ie6 point, the massi(e e?pansion o5 the so5t6are industry is 5orcing de(e8opers to use a8ready imp8emented 8ibraries, ser(ices and 5rame6or0s to de(e8op so5t6are 6ithin e(er shorter periods o5 time$ 2he ne6 de(e8opers are trained to use (I 6ou8d say more o5ten) a8ready de(e8oped so5t6are components, to comp8ete the de(e8opment 1uic0er$ 2hey just p8ug in an e?isting 8ibrary and some ho6 manage to achie(e the re1uirements$ But the sad part o5 the story is, that they ne(er get a training to de5ine, design the architecture 5or, and imp8ement such components$ 7s the number o5 years pass by, these de(e8opers become 8eads and a8so so5t6are architects$ 2heir tit8es change, but the o8d 8egacy o5 not understanding, o5 not ha(ing any architectura8 e?perience continues, creating a (acuum o5 good architects$ 2he bottom 8ine is that on8y a sma88 percentage o5 de(e8opers 0no6 ho6 to design a tru8y object oriented system$ 2he so8ution to this prob8em is getting harder e(ery day as the aggressi(e nature o5 the so5t6are industry does not support an easy adjustment to e?isting processes, and a8so the re8ated on8ine teaching materia8s are either comp8e? or 8ess practica8 or sometimes e(en 6rong$ 2he most o5 them use impractica8, irre8e(ant e?amp8es o5 shapes, anima8s and many other physica8 6or8d entities to teach concepts o5 so5t6are architecture$ 2here are on8y (ery 5e6 good business*oriented design re5erences$ @n5ortunate8y, I myse85 am no e?ception and am a resu8t o5 this (ery same system$ I got the same education that a88 o5 you did, and a8so re5erred to the same resource set you a88 read$ Coming bac0 to the initia8 point, I noticed that there is a 0no68edge gap, increasing e(ery day, bet6een the architects 6ho 0no6 ho6 to architect a system proper8y and the others 6ho do not 0no6$ 2he ones, 6ho 0no6, 0no6 it right$ But the ones, 6ho do not 0no6, 0no6 nothing$ ust 8i0e the 6or8dGs 6ea8th distribution, it is an unba8anced distribution o5 0no68edge$

2. Background
2his artic8e began a5ter reading and hearing the 1uestions ne6 de(e8opers ha(e, on basics o5 so5t6are architecture$ 2here are some good artic8es out there, but sti88 de(e8opers strugg8e to understand the basic concepts, and more important8y, the 6ay to app8y them correct8y$ 7s I see it, ne6comers 6i88 a86ays strugg8e to understand a precise de5inition o5 a ne6 concept, because it is a86ays a ne6 and hence un5ami8iar idea$ 2he one, 6ho has e?perience, understands the meaning, but the one 6ho doesnGt, strugg8es to understand the (ery same de5inition$ It is 8i0e that$ ;mp8oyers 6ant e?perienced emp8oyees$ 4o they say, you need to ha(e e?perience to get a job$ But ho6 the he88 is one supposed to ha(e

that e?perience i5 no one is 6i88ing to gi(e him a job. 7s in the genera8 case, the start 6ith so5t6are architecture is no e?ception$ It 6i88 be di55icu8t$ 3hen you start to design your (ery 5irst system, you 6i88 try to app8y e(erything you 0no6 or 8earned 5rom e(ery6here$ Hou 6i88 5ee8 that an inter5ace needs to be de5ined 5or e(ery c8ass, 8i0e I did once$ Hou 6i88 5ind it harder to understand 6hen and 6hen not to do something$ ust prepare to go through a pain5u8 process$ Others 6i88 critici>e you, may 8augh at you and say that the 6ay you ha(e designed it is 6rong$ Cisten to them, and 8earn continuous8y$ In this process you 6i88 a8so ha(e to read and thin0 a 8ot$ I hope that this artic8e 6i88 gi(e you the right start 5or that 8ong journey$ IThe knowledge of the actions of great men, acquired by long experience in contemporary affairs, and a continual study of antiquity J K I read this phrase 6hen I 6as reading the boo0 named IThe Art of WarJ, seems app8icab8e here, isnGt it.

3. Prerequisites
2his artic8e is an e55ort to pro(ide an accurate in5ormation poo8 5or ne6 de(e8opers on the basics o5 so5t6are architecture, 5ocusing on Object Oriented Programming (OOP)$ I5 you are a de(e8oper, 6ho has a minimum o5 three or more years o5 continuous de(e8opment e?perience and has that hunger to 8earn more, to step*in to the ne?t 8e(e8 to become a so5t6are architect, this artic8e is 5or you$

4. The Main Content 4.1. What is Soft are !rchitecture"

4o5t6are 7rchitecture is de5ined to be the ru8es, heuristics and patterns go(erningL

Partitioning the prob8em and the system to be bui8t into discrete pieces 2echni1ues used to create inter5aces bet6een these pieces 2echni1ues used to manage o(era88 structure and 58o6 2echni1ues used to inter5ace the system to its en(ironment 7ppropriate use o5 de(e8opment and de8i(ery approaches, techni1ues and too8s$

4.2. Wh# !rchitecture is i$%ortant"

2he primary goa8 o5 so5t6are architecture is to de5ine the non*5unctiona8 re1uirements o5 a system and de5ine the en(ironment$ 2he detai8ed design is 5o88o6ed by a de5inition o5

ho6 to de8i(er the 5unctiona8 beha(ior 6ithin the architectura8 ru8es$ 7rchitecture is important because itL

Contro8s comp8e?ity ;n5orces best practices =i(es consistency and uni5ormity Increases predictabi8ity ;nab8es re*use$

4.3. What is OOP"

OOP is a design phi8osophy$ It stands 5or Object Oriented Programming$ Object*Oriented Programming (OOP) uses a di55erent set o5 programming 8anguages than o8d procedura8 programming 8anguages (C, Pascal, etc$)$ ;(erything in OOP is grouped as se85 sustainab8e Mob ectsM$ :ence, you gain re*usabi8ity by means o5 5our main object*oriented programming concepts$ In order to c8ear8y understand the object orientation, 8etGs ta0e your IhandJ as an e?amp8e$ 2he IhandJ is a c8ass$ Hour body has t6o objects o5 type hand, named 8e5t hand and right hand$ 2heir main 5unctions are contro88ed) managed by a set o5 e8ectrica8 signa8s sent through your shou8ders (through an inter5ace)$ 4o the shou8der is an inter5ace 6hich your body uses to interact 6ith your hands$ 2he hand is a 6e88 architected c8ass$ 2he hand is being re*used to create the 8e5t hand and the right hand by s8ight8y changing the properties o5 it$

4.4. What is an O&'ect"

7n object can be considered a MthingM that can per5orm a set o5 re(ated acti(ities$ 2he set o5 acti(ities that the object per5orms de5ines the objectFs beha(ior$ Dor e?amp8e, the hand can grip something or a !tudent (ob ect) can gi(e the name or address$ In pure OOP terms an object is an instance o5 a c8ass$

4.). What is a C(ass"

7 class is simp8y a representation o5 a type o5 ob ect$ It is the b8ueprint) p8an) temp8ate that describe the detai8s o5 an ob ect$ 7 c8ass is the b8ueprint 5rom 6hich the indi(idua8 objects are created$ Class is composed o5 three thingsL a name, attributes, and operations$ Co88apse N Copy Code
public class Student { }

7ccording to the samp8e gi(en be8o6 6e can say that the student object, named ob ect!tudent, has created out o5 the !tudent c8ass$

Co88apse N Copy Code

Student objectStudent = new Student();

In rea8 6or8d, youF88 o5ten 5ind many indi(idua8 objects a88 o5 the same 0ind$ 7s an e?amp8e, there may be thousands o5 other bicyc8es in e?istence, a88 o5 the same ma0e and mode8$ ;ach bicyc8e has bui8t 5rom the same b8ueprint$ In object*oriented terms, 6e say that the bicyc8e is an instance o5 the c8ass o5 objects 0no6n as bicyc8es$ In the so5t6are 6or8d, though you may not ha(e rea8i>ed it, you ha(e a8ready used c8asses$ Dor e?amp8e, the Text"ox contro8, you a86ays used, is made out o5 the Text"ox c8ass, 6hich de5ines its appearance and capabi8ities$ ;ach time you drag a Text"ox contro8, you are actua88y creating a ne6 instance o5 the Text"ox c8ass$

4.*. +o

to identif# and design a C(ass"

2his is an artO each designer uses di55erent techni1ues to identi5y c8asses$ :o6e(er according to Object Oriented Aesign Princip8es, there are 5i(e princip8es that you must 5o88o6 6hen design a c8ass,

4EP * 2he 4ing8e Eesponsibi8ity Princip8e * 7 c8ass shou8d ha(e one, and on8y one, reason to change$ OCP * 2he Open C8osed Princip8e * Hou shou8d be ab8e to e?tend a c8asses beha(ior, 6ithout modi5ying it$ C4P * 2he Cis0o( 4ubstitution Princip8e* Aeri(ed c8asses must be substitutab8e 5or their base c8asses$ AIP * 2he Aependency In(ersion Princip8e* Aepend on abstractions, not on concretions$ I4P * 2he Inter5ace 4egregation Princip8e* Ma0e 5ine grained inter5aces that are c8ient speci5ic$ Dor more in5ormation on design princip8es, p8ease re5er to Object Mentor$ 7dditiona88y to identi5y a c8ass correct8y, you need to identi5y the 5u88 8ist o5 8ea5 8e(e8 5unctions) operations o5 the system (granu8ar 8e(e8 use cases o5 the system)$ 2hen you can proceed to group each 5unction to 5orm c8asses (c8asses 6i88 group same types o5 5unctions) operations)$ :o6e(er a 6e88 de5ined c8ass must be a meaning5u8 grouping o5 a set o5 5unctions and shou8d support the re*usabi8ity 6hi8e increasing e?pandabi8ity) maintainabi8ity o5 the o(era88 system$ In so5t6are 6or8d the concept o5 di(iding and con1uering is a86ays recommended, i5 you start ana8y>ing a 5u88 system at the start, you 6i88 5ind it harder to manage$ 4o the better approach is to identi5y the modu8e o5 the system 5irst and then dig deep in to each modu8e separate8y to see0 out c8asses$ 7 so5t6are system may consist o5 many c8asses$ But in any case, 6hen you ha(e many, it needs to be managed$ 2hin0 o5 a big organi>ation, 6ith its 6or0 5orce e?ceeding se(era8 thousand emp8oyees (8etGs ta0e one emp8oyee as a one c8ass)$ In order to manage such a 6or0 5orce, you need to ha(e proper management po8icies in p8ace$ 4ame techni1ue can be app8ies to manage c8asses o5 your so5t6are system as 6e88$ In order to manage the c8asses o5 a so5t6are system, and to reduce the comp8e?ity, the system designers use se(era8 techni1ues, 6hich can be grouped under 5our main concepts named ;ncapsu8ation, 7bstraction, Inheritance, and Polymorphism$ 2hese concepts are the 5our main gods o5 OOP 6or8d and in so5t6are term, they are ca88ed 5our main Object Oriented Programming (OOP) Concepts$

4.,. What is -nca%su(ation .or infor$ation hiding/"

2he encapsu8ation is the inc8usion 6ithin a program object o5 a88 the resources need 5or the object to 5unction * basica88y, the methods and the data$ In OOP the encapsu8ation is main8y achie(ed by creating c8asses, the c8asses e?pose pub8ic methods and properties$ 2he c8ass is 0ind o5 a container or capsu8e or a ce88, 6hich encapsu8ate the set o5 methods, attribute and properties to pro(ide its indented 5unctiona8ities to other c8asses$ In that sense, encapsu8ation a8so a88o6s a c8ass to change its interna8 imp8ementation 6ithout hurting the o(era88 5unctioning o5 the system$ 2hat idea o5 encapsu8ation is to hide ho6 a c8ass does it but to a88o6 re1uesting 6hat to do$

In order to modu8ari>e) de5ine the 5unctiona8ity o5 a one c8ass, that c8ass can uses 5unctions) properties e?posed by another c8ass in many di55erent 6ays$ 7ccording to Object Oriented Programming there are se(era8 techni1ues, c8asses can use to 8in0 6ith each other and they are named association, aggregation, and composition$ 2here are se(era8 other 6ays that an encapsu8ation can be used, as an e?amp8e 6e can ta0e the usage o5 an inter5ace$ 2he inter5ace can be used to hide the in5ormation o5 an imp8emented c8ass$ Co88apse N Copy Code
IStudent myStudent = new LocalStudent(); IStudent myStudent = new ForeignStudent();

7ccording to the samp8e abo(e (8etGs assume that #ocal!tudent and $oreign!tudent are imp8emented by the %!tudent inter5ace) 6e can see ho6 #ocal!tudent and $oreign!tudent are hiding their, 8oca8i>e imp8ementing in5ormation through the %!tudent inter5ace$

4.0. What is !ssociation"

7ssociation is a (PaP) re8ationship bet6een t6o c8asses$ It a88o6s one object instance to cause another to per5orm an action on its beha85$ 7ssociation is the more genera8 term that de5ine the re8ationship bet6een t6o c8asses, 6here as the aggregation and composition are re8ati(e8y specia8$ Co88apse N Copy Code
public class StudentRegistrar { public StudentRegistrar (); { new Record anager()!Initiali"e(); } }

In this case 6e can say that there is an association bet6een !tudent&egistrar and &ecord'anager or there is a directiona8 association 5rom !tudent&egistrar to &ecord'anager or 4tudentEegistrar use a (P1seP) &ecord'anager$ 4ince a direction is e?p8icit8y speci5ied, in this case the contro88er c8ass is the !tudent&egistrar$

2o some beginners, association is a con5using concept$ 2he troub8es created not on8y by the association a8one, but 6ith t6o other OOP concepts, that is association, aggregation and composition$ ;(ery one understands association, be5ore aggregation and composition are described$ 2he aggregation or composition cannot be separate8y understood$ I5 you understand the aggregation a8one it 6i88 crac0 the de5inition gi(en 5or association, and i5 you try to understand the composition a8one it 6i88 a86ays threaten the de5inition gi(en 5or aggregation, a88 three concepts are c8ose8y re8ated, hence must study together, by comparing one de5inition to another$ CetGs e?p8ore a88 three and see 6hether 6e can understand the di55erences bet6een these use5u8 concepts$

4.2. What is the difference &et een !ssociation3 !ggregation and Co$%osition"
7ssociation is a (PaP) re8ationship bet6een t6o c8asses, 6here one c8ass use another$ But aggregation describes a specia8 type o5 an association$ 7ggregation is the (P theP) re8ationship bet6een t6o c8asses$ 3hen object o5 one c8ass has an (PhasP) object o5 another, i5 second is a part o5 5irst (containment re8ationship) then 6e ca88ed that there is an aggregation bet6een t6o c8asses$ @n8i0e association, aggregation a86ays insists a direction$ Co88apse N Copy Code
public class #ni$ersity { pri$ate %&ancellor uni$ersity%&ancellor = new %&ancellor(); }

In this case I can say that (ni)ersity aggregate Chancellor or (ni)ersity has an (Phas4aP) Chancellor$ But e(en 6ithout a Chancellor a (ni)ersity can e?ists$ But the $aculties cannot e?ist 6ithout the (ni)ersity, the 8i5e time o5 a $aculty (or Dacu8ties) attached 6ith the 8i5e time o5 the (ni)ersity $ I5 (ni)ersity is disposed the $aculties 6i88 not e?ist$ In that case 6e ca88ed that (ni)ersity is composed o5 $aculties$ 4o that composition can be recogni>ed as a specia8 type o5 an aggregation$

4ame 6ay, as another e?amp8e, you can say that, there is a composite re8ationship in* bet6een a *ey+aluePairCollection and a *ey+aluePair$ 2he t6o mutua88y depend on each other$ $Net and a(a uses the Composite re8ation to de5ine their Co88ections$ I ha(e seen Composition is being used in many other 6ays too$ :o6e(er the more important 5actor, that most peop8e 5orget is the 8i5e time 5actor$ 2he 8i5e time o5 the t6o c8asses that has bond 6ith a composite re8ation mutua88y depend on each other$ I5 you ta0e the $net Co88ection to understand this, there you ha(e the Co88ection ;8ement de5ine inside (it is an inner part, hence ca88ed it is composed o5) the Co88ection, 5arcing the ;8ement to get disposed 6ith the Co88ection$ I5 not, as an e?amp8e, i5 you de5ine the Co88ection and itGs ;8ement to be independent, then the re8ationship 6ou8d be more o5 a type 7ggregation, than a Composition$ 4o the point is, i5 you 6ant to bind t6o c8asses 6ith Composite re8ation, more accurate 6ay is to ha(e a one de5ine inside the other c8ass (ma0ing it a protected or pri(ate c8ass)$ 2his 6ay you are a88o6ing the outer c8ass to 5u85i88 its purpose, 6hi8e tying the 8i5etime o5 the inner c8ass 6ith the outer c8ass$ 4o in summary, 6e can say that aggregation is a specia8 0ind o5 an association and composition is a specia8 0ind o5 an aggregation$ (Association,-Aggregation, -Composition)

4.15. What is !&straction and 6enera(i7ation"

7bstraction is an emphasis on the idea, 1ua8ities and properties rather than the particu8ars (a suppression o5 detai8)$ 2he importance o5 abstraction is deri(ed 5rom its abi8ity to hide irre8e(ant detai8s and 5rom the use o5 names to re5erence objects$ 7bstraction is essentia8 in the construction o5 programs$ It p8aces the emphasis on 6hat an object is or does rather than ho6 it is represented or ho6 it 6or0s$ 2hus, it is the primary means o5 managing comp8e?ity in 8arge programs$ 3hi8e abstraction reduces comp8e?ity by hiding irre8e(ant detai8, genera8i>ation reduces comp8e?ity by rep8acing mu8tip8e entities 6hich per5orm simi8ar 5unctions 6ith a sing8e construct$ =enera8i>ation is the broadening o5 app8ication to encompass a 8arger domain o5 objects o5 the same or di55erent type$ Programming 8anguages pro(ide genera8i>ation through (ariab8es, parameteri>ation, generics and polymorphism$ It p8aces the emphasis on the simi8arities bet6een objects$ 2hus, it he8ps to manage comp8e?ity by co88ecting indi(idua8s into groups and pro(iding a representati(e 6hich can be used to speci5y any indi(idua8 o5 the group$ 7bstraction and genera8i>ation are o5ten used together$ 7bstracts are genera8i>ed through parameteri>ation to pro(ide greater uti8ity$ In parameteri>ation, one or more parts o5 an entity are rep8aced 6ith a name 6hich is ne6 to the entity$ 2he name is used as a parameter$ 3hen the parameteri>ed abstract is in(o0ed, it is in(o0ed 6ith a binding o5 the parameter to an argument$

4.11. What is an !&stract c(ass"

7bstract c8asses, 6hich dec8ared 6ith the abstract 0ey6ord, cannot be instantiated$ It can on8y be used as a super*c8ass 5or other c8asses that e?tend the abstract c8ass$ 7bstract c8ass is the concept and imp8ementation gets comp8eted 6hen it is being rea8i>ed by a subc8ass$ In addition to this a c8ass can inherit on8y 5rom one abstract c8ass (but a c8ass may imp8ement many inter5aces) and must o(erride a88 its abstract methods) properties and may o(erride (irtua8 methods) properties$ 7bstract c8asses are idea8 6hen imp8ementing 5rame6or0s$ 7s an e?amp8e, 8etGs study the abstract c8ass named #ogger"ase be8o6$ P8ease care5u88y read the comments as it 6i88 he8p you to understand the reasoning behind this code$ Co88apse N Copy Code
public abstract class Logger'ase { ((( )summary* ((( +ield is pri$ate, so it intend to use inside t&e class only ((( )(summary* pri$ate log-net!ILog logger = null; ((( )summary* ((( protected, so it only $isible +or in&erited class ((( )(summary* protected Logger'ase() { (( .&e pri$ate object is created inside t&e constructor logger = log-net!Log anager!/etLogger(t&is!Log0re+i1); (( .&e additional initiali"ation is done immediately a+ter log-net!%on+ig!23 %on+igurator!%on+igure(); } ((( )summary* ((( 4&en you de+ine t&e property as abstract, ((( it +orces t&e in&erited class to o$erride t&e Log0re+i1 ((( So, wit& t&e &elp o+ t&is tec&ni5ue t&e log can be made, ((( inside t&e abstract class itsel+, irrespecti$e o+ it origin! ((( I+ you study care+ully you will +ind a reason +or not to &a$e 6set7 met&od &ere! ((( )(summary* protected abstract System!.ype Log0re+i1 { get; } ((( )summary* ((( Simple log met&od, ((( w&ic& is only $isible +or in&erited classes ((( )(summary* ((( )param name=8message8*)(param* protected $oid Log9rror(string message) { i+ (t&is!logger!Is9rror9nabled) { t&is!logger!9rror(message); } } ((( ((( ((( ((( )summary* 0ublic properties w&ic& e1poses to in&erited class and all ot&er classes t&at &a$e access to in&erited class )(summary*

public bool Is.&isLog9rror { get { return t&is!logger!Is9rror9nabled; } } }

2he idea o5 ha(ing this c8ass as an abstract is to de5ine a 5rame6or0 5or e?ception 8ogging$ 2his c8ass 6i88 a88o6 a88 subc8ass to gain access to a common e?ception 8ogging modu8e and 6i88 5aci8itate to easi8y rep8ace the 8ogging 8ibrary$ By the time you de5ine the #ogger"ase, you 6ou8dnGt ha(e an idea about other modu8es o5 the system$ But you do ha(e a concept in mind and that is, i5 a c8ass is going to 8og an e?ception, they ha(e to inherit the #ogger"ase$ In other 6ord the #ogger"ase pro(ide a 5rame6or0 5or e?ception 8ogging$ CetGs try to understand each 8ine o5 the abo(e code$ Ci0e any other c8ass, an abstract c8ass can contain 5ie8ds, hence I used a pri(ate 5ie8d named 8ogger dec8are the %#og inter5ace o5 the 5amous 8og#net 8ibrary$ 2his 6i88 a88o6 the #oggerbase c8ass to contro8, 6hat to use, 5or 8ogging, hence, 6i88 a88o6 changing the source 8ogger 8ibrary easi8y$ 2he access modi5ier o5 the constructor o5 the #ogger"ase is protected$ 2he pub8ic constructor has no use 6hen the c8ass is o5 type abstract$ 2he abstract c8asses are not a88o6ed to instantiate the c8ass$ 4o I 6ent 5or the protected constructor$ 2he abstract property named CogPre5i? is an important one$ It en5orces and guarantees to ha(e a (a8ue 5or #ogPrefix (#ogPrefix uses to obtain the detai8 o5 the source c8ass, 6hich the e?ception has occurred) 5or e(ery subc8ass, be5ore they in(o0e a method to 8og an error$ 2he method named #og.rror is protected, hence e?posed to a88 subc8asses$ Hou are not a88o6ed or rather you cannot ma0e it pub8ic, as any c8ass, 6ithout inheriting the #ogger"ase cannot use it meaning5u88y$ CetGs 5ind out 6hy the property named %sThis#og.rror is pub8ic$ It may be important) use5u8 5or other associated c8asses o5 an inherited c8ass to 0no6 6hether the associated member 8ogs its errors or not$ 7part 5rom these you can a8so ha(e (irtua8 methods de5ined in an abstract c8ass$ 2he (irtua8 method may ha(e its de5au8t imp8ementation, 6here a subc8ass can o(erride it 6hen re1uired$ 788 and a88, the important 5actor here is that a88 OOP concepts shou8d be used care5u88y 6ith reasons, you shou8d be ab8e to 8ogica88y e?p8ain, 6hy you ma0e a property a pub8ic or a 5ie8d a pri(ate or a c8ass an abstract$ 7dditiona88y, 6hen architecting 5rame6or0s, the OOP concepts can be used to 5orce5u88y guide the system to be de(e8oped in the 6ay 5rame6or0 architectGs 6anted it to be architected initia88y$

4.12. What is an Interface"

In summary the Inter5ace separates the imp8ementation and de5ines the structure, and this concept is (ery use5u8 in cases 6here you need the imp8ementation to be interchangeab8e$ 7part 5rom that an inter5ace is (ery use5u8 6hen the imp8ementation

changes 5re1uent8y$ 4ome say you shou8d de5ine a88 c8asses in terms o5 inter5aces, but I thin0 recommendation seems a bit e?treme$ Inter5ace can be used to de5ine a generic temp8ate and then one or more abstract c8asses to de5ine partia8 imp8ementations o5 the inter5ace$ Inter5aces just speci5y the method dec8aration (imp8icit8y pub8ic and abstract) and can contain properties (6hich are a8so imp8icit8y pub8ic and abstract)$ Inter5ace de5inition begins 6ith the 0ey6ord inter5ace$ 7n inter5ace 8i0e that o5 an abstract c8ass cannot be instantiated$ I5 a c8ass that imp8ements an inter5ace does not de5ine a88 the methods o5 the inter5ace, then it must be dec8ared abstract and the method de5initions must be pro(ided by the subc8ass that e?tends the abstract c8ass$ In addition to this an inter5aces can inherit other inter5aces$ 2he samp8e be8o6 6i88 pro(ide an inter5ace 5or our #ogger"ase abstract c8ass$ Co88apse N Copy Code
public inter+ace ILogger { bool Is.&isLog9rror { get; } }

4.13. What is the difference &et een a C(ass and an Interface"

In $Net) CQ a class can be de5ined to imp8ement an interface and a8so it supports mu8tip8e imp8ementations$ 3hen a class imp8ements an interface, an ob ect o5 such class can be encapsu8ated inside an interface$ I5 'y#ogger is a c8ass, 6hich imp8ements %#ogger, there 6e can 6rite Co88apse N Copy Code
ILogger log = new yLogger();

7 class and an interface are t6o di55erent types (conceptua88y)$ 2heoretica88y a class emphasis the idea o5 encapsu8ation, 6hi8e an interface emphasis the idea o5 abstraction (by suppressing the detai8s o5 the imp8ementation)$ 2he t6o poses a c8ear separation 5rom one to another$ 2here5ore it is (ery di55icu8t or rather impossib8e to ha(e an e55ecti(e meaning5u8 comparison bet6een the t6o, but it is (ery use5u8 and a8so meaning5u8 to ha(e a comparison bet6een an inter5ace and an abstract c8ass$

4.14. What is the difference &et een an Interface and an !&stract c(ass"
2here are 1uite a big di55erence bet6een an interface and an abstract class, e(en though both 8oo0 simi8ar$
o o o o o o
Inter5ace de5inition begins 6ith a 0ey6ord inter5ace so it is o5 type inter5ace 7bstract c8asses are dec8ared 6ith the abstract 0ey6ord so it is o5 type c8ass Inter5ace has no imp8ementation, but they ha(e to be imp8emented$ 7bstract c8assGs methods can ha(e imp8ementations and they ha(e to be e?tended$ Inter5aces can on8y ha(e method dec8aration (imp8icit8y pub8ic and abstract) and 5ie8ds (imp8icit8y pub8ic static) 7bstract c8assGs methods canGt ha(e imp8ementation on8y 6hen dec8ared abstract$

o o o o o o o o o

Inter5ace can inherit more than one inter5aces 7bstract c8ass can imp8ement more than one inter5aces, but can inherit on8y one c8ass 7bstract c8ass must o(erride a88 abstract method and may o(erride (irtua8 methods Inter5ace can be used 6hen the imp8ementation is changing 7bstract c8ass can be used to pro(ide some de5au8t beha(ior 5or a base c8ass$ Inter5ace ma0es imp8ementation interchangeab8e Inter5ace increase security by hiding the imp8ementation 7bstract c8ass can be used 6hen imp8ementing 5rame6or0 7bstract c8asses are an e?ce88ent 6ay to create p8anned inheritance hierarchies and a8so to use as non*8ea5 c8asses in c8ass hierarchies$

7bstract c8asses 8et you de5ine some beha(iorsO they 5orce your subc8asses to pro(ide others$ Dor e?amp8e, i5 you ha(e an app8ication 5rame6or0, an abstract c8ass can be used to pro(ide the de5au8t imp8ementation o5 the ser(ices and a88 mandatory modu8es such as e(ent 8ogging and message hand8ing etc$ 2his approach a88o6s the de(e8opers to de(e8op the app8ication 6ithin the guided he8p pro(ided by the 5rame6or0$ :o6e(er, in practice 6hen you come across 6ith some app8ication*speci5ic 5unctiona8ity that on8y your app8ication can per5orm, such as startup and shutdo6n tas0s etc$ 2he abstract base c8ass can dec8are (irtua8 shutdo6n and startup methods$ 2he base c8ass 0no6s that it needs those methods, but an abstract c8ass 8ets your c8ass admit that it doesnFt 0no6 ho6 to per5orm those actionsO it on8y 0no6s that it must initiate the actions$ 3hen it is time to start up, the abstract c8ass can ca88 the startup method$ 3hen the base c8ass ca88s this method, it can e?ecute the method de5ined by the chi8d c8ass$

4.1). What is I$%(icit and -8%(icit Interface I$%(e$entations"

7s mentioned be5ore $Net support mu8tip8e imp8ementations, the concept o5 imp8icit and e?p8icit imp8ementation pro(ide sa5e 6ay to imp8ement methods o5 mu8tip8e inter5aces by hiding, e?posing or preser(ing identities o5 each o5 inter5ace methods, e(en 6hen the method signatures are the same$ CetFs consider the inter5aces de5ined be8o6$ Co88apse N Copy Code
inter+ace I2isposable { $oid 2ispose(); }

:ere you can see that the c8ass !tudent has imp8icit8y and e?p8icit8y imp8emented the method named /ispose01 (ia /ispose and %/isposable2/ispose$ Co88apse N Copy Code
class Student : I2isposable { public $oid 2ispose() { %onsole!4riteLine(8Student!2ispose8); } $oid I2isposable!2ispose() { %onsole!4riteLine(8I2isposable!2ispose8); }

4.1*. What is Inheritance"

7bi8ity o5 a ne6 c8ass to be created, 5rom an e?isting c8ass by e?tending it, is ca88ed inheritance$

Co88apse N Copy Code

public class 91ception { } public class I391ception : 91ception { }

7ccording to the abo(e e?amp8e the ne6 c8ass (%O.xception), 6hich is ca88ed the deri(ed c8ass or subc8ass, inherits the members o5 an e?isting c8ass (.xception), 6hich is ca88ed the base c8ass or super*c8ass$ 2he c8ass %O.xception can e?tend the 5unctiona8ity o5 the c8ass ;?ception by adding ne6 types and methods and by o(erriding e?isting ones$ ust 8i0e abstraction is c8ose8y re8ated 6ith genera8i>ation, the inheritance is c8ose8y re8ated 6ith specia8i>ation$ It is important to discuss those t6o concepts together 6ith genera8i>ation to better understand and to reduce the comp8e?ity$ One o5 the most important re8ationships among objects in the rea8 6or8d is specia8i>ation, 6hich can be described as the Iis4aJ re8ationship$ 3hen 6e say that a dog is a mamma8, 6e mean that the dog is a specia8i>ed 0ind o5 mamma8$ It has a88 the characteristics o5 any mamma8 (it bears 8i(e young, nurses 6ith mi80, has hair), but it specia8i>es these characteristics to the 5ami8iar characteristics o5 canis domesticus$ 7 cat is a8so a mamma8$ 7s such, 6e e?pect it to share certain characteristics 6ith the dog that are genera8i>ed in Mamma8, but to di55er in those characteristics that are specia8i>ed in cats$ 2he specia8i>ation and genera8i>ation re8ationships are both reciproca8 and hierarchica8$ 4pecia8i>ation is just the other side o5 the genera8i>ation coinL Mamma8 genera8i>es 6hat is common bet6een dogs and cats, and dogs and cats specia8i>e mamma8s to their o6n speci5ic subtypes$ 4imi8ar8y, as an e?amp8e you can say that both %O.xception and !ecurity.xception are o5 type ;?ception$ 2hey ha(e a88 characteristics and beha(iors o5 an ;?ception, 2hat mean the %O.xception is a specia8i>ed 0ind o5 ;?ception$ 7 !ecurity.xception is a8so an

.xception$ 7s such, 6e e?pect it to share certain characteristic 6ith %O.xception that are genera8i>ed in ;?ception, but to di55er in those characteristics that are specia8i>ed in !ecurity.xceptions$ In other 6ords, ;?ception genera8i>es the shared characteristics o5 both %O.xception and !ecurity.xception, 6hi8e %O.xception and !ecurity.xception specia8i>e 6ith their characteristics and beha(iors$ In OOP, the specia8i>ation re8ationship is imp8emented using the princip8e ca88ed inheritance$ 2his is the most common and most natura8 and 6ide8y accepted 6ay o5 imp8ement this re8ationship$

4.1,. What is Po(#$or%his$s"

Po8ymorphisms is a generic term that means Fmany shapesF$ More precise8y Polymorphisms means the abi8ity to re1uest that the same operations be per5ormed by a 6ide range o5 di55erent types o5 things$ 7t times, I used to thin0 that understanding Object Oriented Programming concepts ha(e made it di55icu8t since they ha(e grouped under 5our main concepts, 6hi8e each concept is c8ose8y re8ated 6ith one another$ :ence one has to be e?treme8y care5u8 to correct8y understand each concept separate8y, 6hi8e understanding the 6ay each re8ated 6ith other concepts$ In OOP the polymorphisms is achie(ed by using many di55erent techni1ues named method o(er8oading, operator o(er8oading and method o(erriding,

4.10. What is Method O9er(oading"

2he method o(er8oading is the abi8ity to de5ine se(era8 methods a88 6ith the same name$ Co88apse N Copy Code
public class yLogger { public $oid Log9rror(91ception e) { (( Implementation goes &ere } public bool Log9rror(91ception e, string message) { (( Implementation goes &ere } }

4.12. What is O%erator O9er(oading"

2he operator o(er8oading (8ess common8y 0no6n as ad*hoc polymorphisms) is a speci5ic case o5 polymorphisms in 6hich some or a88 o5 operators 8i0e R, * or SS are treated as po8ymorphic 5unctions and as such ha(e di55erent beha(iors depending on the types o5 its arguments$ Co88apse N Copy Code
public class %omple1 { pri$ate int real; public int Real { get { return real; } } pri$ate int imaginary;

public int Imaginary { get { return imaginary; } } public %omple1(int real, int imaginary) { t&is!real = real; t&is!imaginary = imaginary; } public static %omple1 operator ;(%omple1 c<, %omple1 c=) { return new %omple1(c<!Real ; c=!Real, c<!Imaginary ; c=!Imaginary); } }

I abo(e e?amp8e I ha(e o(er8oaded the p8us operator 5or adding t6o comp8e? numbers$ 2here the t6o properties named Eea8 and Imaginary has been dec8ared e?posing on8y the re1uired IgetJ method, 6hi8e the objectGs constructor is demanding 5or mandatory rea8 and imaginary (a8ues 6ith the user de5ined constructor o5 the c8ass$

4.25. What is Method O9erriding"

Method o(erriding is a 8anguage 5eature that a88o6s a subc8ass to o(erride a speci5ic imp8ementation o5 a method that is a8ready pro(ided by one o5 its super*c8asses$ 7 subc8ass can gi(e its o6n de5inition o5 methods but need to ha(e the same signature as the method in its super*c8ass$ 2his means that 6hen o(erriding a method the subc8assFs method has to ha(e the same name and parameter 8ist as the super*c8assFs o(erridden method$ Co88apse N Copy Code
using System; public class %omple1 { pri$ate int real; public int Real { get { return real; } } pri$ate int imaginary; public int Imaginary { get { return imaginary; } } public %omple1(int real, int imaginary) { t&is!real = real; t&is!imaginary = imaginary; } public static %omple1 operator ;(%omple1 c<, %omple1 c=) { return new %omple1(c<!Real ; c=!Real, c<!Imaginary ; c=!Imaginary); } public o$erride string .oString() { return (String!Format(8{>} ; {<}i8, real, imaginary)); } }

In abo(e e?amp8e I ha(e e?tended the imp8ementation o5 the samp8e Comp8e? c8ass gi(en under operator o(er8oading section$ 2his c8ass has one o(erridden method named

3To!tring4, 6hich o(erride the de5au8t imp8ementation o5 the standard 3To!tring4 method to support the correct string con(ersion o5 a comp8e? number$ Co88apse N Copy Code
%omple1 num< = new %omple1(?, @); %omple1 num= = new %omple1(A, B); (( Cdd two %omple1 numbers using t&e (( o$erloaded plus operator %omple1 sum = num< ; num=; (( 0rint t&e numbers and t&e sum (( using t&e o$erriden .oString met&od %onsole!4riteLine(8({>}) ; ({<}) = {=}8, num<, num=, sum); %onsole!ReadLine();

4.21. What is a 1se case"

7 use case is a thing an actor percei(es 5rom the system$ 7 use case maps actors 6ith 5unctions$ Important8y, the actors need not be peop8e$ 7s an e?amp8e a system can per5orm the ro8e o5 an actor, 6hen it communicate 6ith another system$

In another ang8e a use case encodes a typica8 user interaction 6ith the system$ In particu8ar, itL

Captures some user*(isib8e 5unction$ 7chie(es some concrete goa8 5or the user$

7 comp8ete set o5 use cases 8arge8y de5ines the re1uirements 5or your systemL e(erything the user can see, and 6ou8d 8i0e to do$ 2he be8o6 diagram contains a set o5 use cases that describes a simp8e 8ogin modu8e o5 a gaming 6ebsite$

4.22. What is a C(ass :iagra$"

7 c8ass diagrams are 6ide8y used to describe the types o5 objects in a system and their re8ationships$ C8ass diagrams mode8 c8ass structure and contents using design e8ements such as c8asses, pac0ages and objects$ C8ass diagrams describe three di55erent perspecti(es 6hen designing a system, conceptua8, speci5ication, and imp8ementation$ 2hese perspecti(es become e(ident as the diagram is created and he8p so8idi5y the design$ 2he C8ass diagrams, physica8 data mode8s, a8ong 6ith the system o(er(ie6 diagram are in my opinion the most important diagrams that suite the current day rapid app8ication de(e8opment re1uirements$ @MC NotationsL

4.23. What is a Package :iagra$"

Pac0age diagrams are used to re58ect the organi>ation o5 pac0ages and their e8ements$ 3hen used to represent c8ass e8ements, pac0age diagrams pro(ide a (isua8i>ation o5 the name*spaces$ In my designs, I use the pac0age diagrams to organi>e c8asses in to di55erent modu8es o5 the system$

4.24. What is a Sequence :iagra$"

7 se1uence diagrams mode8 the 58o6 o5 8ogic 6ithin a system in a (isua8 manner, it enab8e both to document and (a8idate your 8ogic, and are used 5or both ana8ysis and design purposes$ 4e1uence diagrams are the most popu8ar @MC arti5act 5or dynamic mode8ing, 6hich 5ocuses on identi5ying the beha(ior 6ithin your system$

4.2). What is t o4tier architecture"

2he t6o*tier architecture is re5ers to c8ient) ser(er architectures as 6e88, the term c8ient) ser(er 6as 5irst used in the "<%!s in re5erence to persona8 computers (PCs) on a net6or0$ 2he actua8 c8ient) ser(er mode8 started gaining acceptance in the 8ate "<%!s, and 8ater it 6as adapted to 3or8d 3ide 3eb programming$ 7ccording to the modern days use o5 t6o*tier architecture the user inter5aces (or 6ith 74P$N;2, a88 6eb pages) runs on the c8ient and the database is stored on the ser(er$ 2he actua8 app8ication 8ogic can run on either the c8ient or the ser(er$ 4o in this case the user inter5aces are direct8y access the database$ 2hose can a8so be non*inter5ace processing engines, 6hich pro(ide so8utions to other remote) 8oca8 systems$ In either

case, today the t6o*tier mode8 is not as reputed as the three*tier mode8$ 2he ad(antage o5 the t6o*tier design is its simp8icity, but the simp8icity comes 6ith the cost o5 sca8abi8ity$ 2he ne6er three*tier architecture, 6hich is more 5amous, introduces a midd8e tier 5or the app8ication 8ogic$

4.2*. What is three4tier architecture"

2he three tier so5t6are architecture (a8so 0no6n as three 8ayer architectures) emerged in the "<<!s to o(ercome the 8imitations o5 the t6o tier architecture$ 2his architecture has aggressi(e8y customi>ed and adopted by modern day system designer to 6eb systems$ 2hree*tier is a c8ient*ser(er architecture in 6hich the user inter5ace, 5unctiona8 process 8ogic, data storage and data access are de(e8oped and maintained as independent modu8es, some time on separate p8at5orms$ 2he term Mthree,tierM or Mthree,layerM, as 6e88 as the concept o5 mu8ti*tier architectures (o5ten re5ers to as three*tier architecture), seems to ha(e originated 6ithin Eationa8 4o5t6are$

2he '*2ier architecture has the 5o88o6ing three tiers$ Presentation Tier or We& Ser9erL @ser Inter5ace, disp8aying) accepting data) input to) 5rom the user 2. !%%(ication ;ogic< Business ;ogic< Transaction Tier or !%%(ication Ser9er L Aata (a8idation, acceptabi8ity chec0 be5ore being added to the database and a88 other business) app8ication speci5ic operations 3. :ata Tier or :ata&ase ser9erL 4imp8e reading and 6riting method to database or any other storage, connection, command, stored procedures etc

1.

4.2,. What is M=C architecture"

2he Mode8*=ie6*Contro88er ('+C) architecture separates the mode8ing o5 the domain, the presentation, and the actions based on user input into three separate c8asses$

@n5ortunate8y, the popu8arity o5 this pattern has resu8ted in a number o5 5au8ty usagesO each techno8ogy (5a)a, A!P26.T etc) has de5ined it in their o6n 6ay ma0ing it di55icu8t to understand$ In particu8ar, the term Mcontro88erM has been used to mean di55erent things in di55erent conte?ts$ 2he de5initions gi(en be88o6 are the c8oses possib8e ones I 5ound 5or 74P$N;2 (ersion o5 '+C$

1.

Mode(L /ata!et and typed /ata!et (some times business object, object co88ection, TMC etc) are the most common use o5 the mode8$ 2. =ie L 2he A!P7 and A!C7 5i8es genera88y hand8e the responsibi8ities o5 the (ie6$ 3. Contro((ersL 2he hand8ing o5 e(ents or the contro88ing is usua88y done in the code* behind c8ass$ In a comp8e? n*tier distributed system the '+C architecture p8ace the (ita8 ro8e o5 organi>ing the presentation tier o5 the system$

4.20. What is SO!"

7 ser(ice*oriented architecture is essentia88y a co88ection o5 ser(ices$ 2hese ser(ices communicate 6ith each other$ 2he communication can in(o8(e either simp8e data passing or it cou8d in(o8(e t6o or more ser(ices coordinating some acti(ity$ 4ome means o5 connecting ser(ices to each other is needed$ 2he $Net techno8ogy introduces the 4O7 by mean o5 6eb ser(ices$

2he 4O7 can be used as the concept to connect mu8tip8e systems to pro(ide ser(ices$ It has itFs great share in the 5uture o5 the I2 6or8d$ 7ccording to the imaginary diagram abo(e, 6e can see ho6 the 4er(ice Oriented 7rchitecture is being used to pro(ide a set o5 centra8i>ed ser(ices to the citi>ens o5 a

country$ 2he citi>ens are gi(en a uni1ue identi5ying card, 6here that card carries a88 persona8 in5ormation o5 each citi>en$ ;ach ser(ice centers such as shopping comp8e?, hospita8, station, and 5actory are e1uipped 6ith a computer system 6here that system is connected to a centra8 ser(er, 6hich is responsib8e o5 pro(iding ser(ice to a city$ 7s an e?amp8e 6hen a customer enter the shopping comp8e? the regiona8 computer system report it to the centra8 ser(er and obtain in5ormation about the customer be5ore pro(iding access to the premises$ 2he system 6e8comes the customer$ 2he customer 5inished the shopping and then by the time he 8ea(es the shopping comp8e?, he 6i88 be as0ed to go through a bi88ing process, 6here the regiona8 computer system 6i88 manage the process$ 2he payment 6i88 be automatica88y hand8ed 6ith the input detai8s obtain 5rom the customer identi5ying card$ 2he regiona8 system 6i88 report to the city (computer system o5 the city) 6hi8e the city 6i88 report to the country (computer system o5 the country)$

4.22. What is the :ata !ccess ;a#er"

2he data access 8ayer (A7C), 6hich is a 0ey part o5 e(ery n*tier system, is main8y consist o5 a simp8e set o5 code that does basic interactions 6ith the database or any other storage de(ice$ 2hese 5unctiona8ities are o5ten re5erred to as CE@A (Create, Eetrie(e, @pdate, and Ae8ete)$ 2he data access 8ayer need to be generic, simp8e, 1uic0 and e55icient as much as possib8e$ It shou8d not inc8ude comp8e? app8ication) business 8ogics$ I ha(e seen systems 6ith 8engthy, comp8e? store procedures (4P), 6hich run through se(era8 cases be5ore doing a simp8e retrie(a8$ 2hey contain not on8y most part o5 the business 8ogic, but app8ication 8ogic and user inter5ace 8ogic as 6e88$ I5 4P is getting 8onger and comp8icated, then it is a good indication that you are burring your business 8ogic inside the data access 8ayer$

4.35. What is the Business ;ogic ;a#er"

I 0no6 5or a 5act that this is a 1uestion 5or most, but 5rom the other hand by reading many artic8es I ha(e become a6are that not e(eryone agrees to 6hat business 8ogic actua88y is, and in many cases itFs just the bridge in bet6een the presentation 8ayer and the data access 8ayer 6ith ha(ing nothing much, e?cept ta0ing 5rom one and passing to the other$ In some other cases, it is not e(en been 6e88 thought out, they just ta0e the 8e5to(ers 5rom the presentation 8ayer and the data access 8ayer then put them in another 8ayer 6hich automatica88y is ca88ed the business 8ogic 8ayer$ :o6e(er there are no god said things that cannot be changed in so5t6are 6or8d$ Hou can change as and 6hen you 5ee8 com5ortab8e that the method you app8y is 58e?ib8e enough to support the gro6th o5 your system$ 2here are many great 6ays, but be care5u8 6hen se8ecting them, they can o(er comp8icating the simp8e system$ It is a ba8ance one needs to 5ind 6ith their e?perience$ 7s a genera8 ad(ice 6hen you de5ine business entities, you must decide ho6 to map the data in your tab8es to correct8y de5ined business entities$ 2he business entities shou8d meaning5u88y de5ine considering (arious types o5 re1uirements and 5unctioning o5 your system$ It is recommended to identi5y the business entities to encapsu8ate the 5unctiona8) @I (@ser Inter5ace) re1uirements o5 your app8ication, rather than de5ine a separate business entity 5or each tab8e o5 your database$ Dor e?amp8e, i5 you 6ant to combine data 5rom coup8e o5 tab8e to bui8d a @I (@ser Inter5ace) contro8 (3eb Contro8), imp8ement that 5unction in the Business Cogic Cayer 6ith a business object that uses coup8e o5 data object to support 6ith your comp8e? business re1uirement$

4.31. What is 6ang of >our .6o>/ :esign Patterns"

2he =ang o5 Dour (=oD) patterns are genera88y considered the 5oundation 5or a88 other patterns$ 2hey are categori>ed in three groupsL Creationa8, 4tructura8, and Beha(iora8$ :ere you 6i88 5ind in5ormation on these important patterns$

Creationa( Patterns
o o o o o
7bstract Dactory Creates an instance o5 se(era8 5ami8ies o5 c8asses Bui8der 4eparates object construction 5rom its representation Dactory Method Creates an instance o5 se(era8 deri(ed c8asses Prototype 7 5u88y initia8i>ed instance to be copied or c8oned 4ing8eton 7 c8ass o5 6hich on8y a sing8e instance can e?ist

Structura( Patterns
o o o o o o o
7dapter Match inter5aces o5 di55erent c8asses Bridge 4eparates an objectGs inter5ace 5rom its imp8ementation Composite 7 tree structure o5 simp8e and composite objects Aecorator 7dd responsibi8ities to objects dynamica88y Dacade 7 sing8e c8ass that represents an entire subsystem D8y6eight 7 5ine*grained instance used 5or e55icient sharing Pro?y 7n object representing another object

Beha9iora( Patterns
o o o o o o o o o o o
Chain o5 Eesp$ 7 6ay o5 passing a re1uest bet6een a chain o5 objects Command ;ncapsu8ate a command re1uest as an object Interpreter 7 6ay to inc8ude 8anguage e8ements in a program Iterator 4e1uentia88y access the e8ements o5 a co88ection Mediator Ae5ines simp8i5ied communication bet6een c8asses Memento Capture and restore an objectFs interna8 state Obser(er 7 6ay o5 noti5ying change to a number o5 c8asses 4tate 78ter an objectFs beha(ior 6hen its state changes 4trategy ;ncapsu8ates an a8gorithm inside a c8ass 2emp8ate Method Ae5er the e?act steps o5 an a8gorithm to a subc8ass Bisitor Ae5ines a ne6 operation to a c8ass 6ithout change

4.32. What is the difference &et een !&stract >actor# and Bui(der design %atterns"
2he t6o design patterns are 5undamenta88y di55erent$ :o6e(er, 6hen you 8earn them 5or the 5irst time, you 6i88 see a con5using simi8arity$ 4o that it 6i88 ma0e harder 5or you to understand them$ But i5 you continue to study e(entua88y, you 6i88 get a5raid o5 design patterns too$ It is 8i0e in5ant phobia, once you get a5raid at your ear8y age, it stays 6ith you 5ore(er$ 4o the resu8t 6ou8d be that you ne(er 8oo0 bac0 at design patterns again$ Cet me see 6hether I can so8(e this brain teaser 5or you$ In the image be8o6, you ha(e both design pattern 8isted in$ I am trying to compare the t6o one on one to identi5y the simi8arities$ I5 you obser(e the 5igure care5u88y, you 6i88 see an easi8y understandab8e co8or pattern (same co8or is used to mar0 the c8asses that are o5 simi8ar 0ind)$

P8ease 5o88o6 up 6ith the numbers in the image 6hen reading the 8isting be8o6$ Mar0 ?1L Both patterns ha(e used a generic c8ass as the entry*c8ass$ 2he on8y di55erence is the name o5 the c8ass$ One pattern has named it as IC8ientJ, 6hi8e the other named it as IAirectorJ$ Mar0 ?2L :ere again the di55erence is the c8ass name$ It is I7bstractDactoryJ 5or one and IBui8derJ 5or the other$ 7dditiona88y both c8asses are o5 type abstract$ Mar0 ?3L Once again both patterns ha(e de5ined t6o generic (3indo6sDactory U ConcreteBui8der) c8asses$ 2hey both ha(e created by inheriting their respecti(e abstract c8ass$ Mar0 ?4L Dina88y, both seem to produce some 0ind o5 a generic output$ No6, 6here are 6e. 7renGt they 8oo0ing a8most identica8. 4o then 6hy are 6e ha(ing t6o di55erent patterns here. CetGs compare the t6o again side by side 5or one 8ast time, but this time, 5ocusing on the di55erences$

Abstract $actoryL ;mphasi>es a 5ami8y o5 product objects (either simp8e or comp8e?) "uilderL Docuses on constructing a comp8e? object step by step Abstract $actoryL Docus on P6hatP is made "uilderL Docus on Pho6P it is made

Abstract $actoryL Docus on de5ining many di55erent types o5 P5actoriesP to bui8d many PproductsP, and it is not a one bui8der 5or just one product "uilderL Docus on bui8ding a one comp8e? but one sing8e PproductP Abstract $actoryL Ae5ers the choice o5 6hat concrete type o5 object to ma0e unti8 run time "uilderL :ide the 8ogic) operation o5 ho6 to compi8e that comp8e? object Abstract $actoryL P;(eryP method ca88 creates and returns di55erent objects "uilderL On8y the P8astP method ca88 returns the object, 6hi8e other ca88s partia88y bui8d the object

4ometimes creationa8 patterns are comp8ementaryL 4o you can join one or many patterns 6hen you design your system$ 7s an e?amp8e bui8der can use one o5 the other patterns to imp8ement 6hich components get bui8t or in another case 7bstract Dactory, Bui8der, and Prototype can use 4ing8eton in their imp8ementations$ 4o the conc8usion 6ou8d be that the t6o design patterns e?ist to reso8(e t6o type o5 business prob8ems, so e(en though they 8oo0 simi8ar, they are not$ I hope that this shed some 8ight to reso8(e the pu>>8e$ I5 you sti88 donGt understand it, then this time it is not you, it has to be me and it is since that I donGt 0no6 ho6 to e?p8ain it$

). What is the Conc(usion"

I donFt thin0, that it is rea8istic trying to ma0e a programming 8anguage be e(erything to e(erybody$ 2he 8anguage becomes b8oated, hard to 8earn, and hard to read i5 e(erything p8us the 0itchen sin0 is thro6n in$ In another 6ord e(ery 8anguage has their 8imitations$ 7s system architect and designer 6e shou8d be ab8e to 5u88y and more important8y correct8y (this a8so mean that you shou8dnGt use a ba88istic missi8e to 0i88 a 58y or hire DBI to catch the 58y) uti8i>e the a(ai8ab8e too8s and 5eatures to bui8d usab8e, sustainab8e, maintainab8e and a8so (ery important8y e?pandab8e so5t6are systems, that 5u88y uti8i>e the 5eature o5 the 8anguage to bring a competiti(e8y ad(ance system to their customers$ In order to do it, the 5oundation o5 a system p8aces a (ita8 ro8e$ 2he design or the architecture o5 a so5t6are system is the 5oundation$ It ho8d the system together, hence designing a system proper8y (this ne(er mean an Po(erP desinging) is the 0ey to the success$ 3hen you ta80 about designing a so5t6are system, the correct hand8ing o5 OOP concept is (ery important$ I ha(e made the abo(e artic8e richer 6ith idea but sti88 0ept it short so that one can 8earn) remind a88 o5 important concept at a g8ance$ :ope you a88 6i88 enjoy reading it$ Dina88y, a5ter reading a88 these, one may argue 6ith me saying that anybody can 6rite a88 these concept de5initions but do I 0no6 ho6) 6hen to app8y them in rea8 6or8d systems$ 4o 5or them to see these concepts being app8ied in rea8 6or8d systems, p8ease chec0 the source code o5 the 8atest o5 my open*source project name Eoc0et Drame6or0$ NoteL Dor ne6bies Eoc0et Drame6or0 is going to be 8itt8e too ad(ance but chec0 it, use it and re(ie6 it i5 you ha(e any 1uestions) criticisms around my design donFt hesitate to shoot them here or there$$

*. What I @eferred"

M4AN CibraryL httpL))msdn2$microso5t$com)en*us)8ibrary)de5au8t$asp? Practica8 7pproach to Computer 4ystems Aesign and 7rchitectureL httpL))666$codeproject$com)useritems)4ystemVAesign$asp IntroductionL 3hat is Object*Oriented Programming.L httpL))666$in5$u5sc$br)poo)sma88ta80)ibm)tutoria8)oop$htm8 Basic Object*Oriented ConceptsL httpL))666$toa$com)pub)oobasics)oobasics$htm

Inheritance and Po8ymorphismW4pecia8i>ation and =enera8i>ationL httpL))en$csharp*on8ine$net)InheritanceVandVPo8ymorphism X;2X%!X<#4pecia8i>ationVandV=enera8i>ation 7bstraction and =enera8i>ationL httpL))cs$66c$edu)Yaabyan)PCBoo0):2MC)7bs=en$htm8 Object Oriented 7na8ysis and Aesign 2eamL httpL))at8as$0ennesa6$edu)Ydbraun)csis#95!)7UA)inde?$htm C8ient)4er(er 4o5t6are 7rchitectures**7n O(er(ie6L httpL))666$sei$cmu$edu)str)descriptions)c8ientser(er$htm8 4er(ice*oriented architecture (4O7) de5initionL httpL))666$ser(ice* architecture$com)6eb*ser(ices)artic8es)ser(ice*orientedVarchitectureVsoaVde5inition$htm8 httpL))666$do5actory$com)Patterns)Patterns$asp? httpL))666$objectmentor$com