Who We Are

1. Who We Are Since 1995, we’ve been building innovative custom solutions specifically designed to meet the unique needs of America’s most recognized companies. If you have a critical project that needs to be done right the first time, you can rely on us. • • We customize solutions that make your software perform to its • fullest potential to meet your specific business objectives. • • We are the ONLY service provider who absolutely guarantee to deliver • innovative, custom solutions that guarantee your satisfaction and success. • • Our Distributed Delivery allows us to best meet your unique needs • and save you money. • • We’re experts who offer you unsurpassed technological knowledge • and experience. • • Everything we do is focused specifically on you, your unique needs, • your success and your complete satisfaction at all times.

2. Michael Kappel, MCPD https://www.mcpvirtualbusinesscard.com/VBCServer/MichaelKappel/profile • • My Website http://MichaelKappel.com • • My vCard http://MJK.tel • • This Presentation http://Solid.Architecture.MichaelKappel.com

3. SDC, CNUG, and APSIG • SDC - Software Development Community • CNUG - Chicago .Net User Group • APPSIG - Architecture Patterns and Practices Special Interest Group *** Disclaimer *** The opinions expressed in this presentation do not necessarily reflect any group I am affiliated with, my employer Magenic, or even me.

4. Innovation, Creativity, Real Solutions, and Tangible Results • Code quality is paramount!What the client can’t see will make or break their investment eventually • Develop in a way the team can maintainUnderstand where your team is at and where they are headed • Knowledge exchangeThere is no time to waste thinking you have nothing to learn • Refactor early and oftenThe earlier problems are detected and eliminated the less they cost • Never spend time on a work around, that you could spend on a fixDeadlines are not really met if you have built in depth • Question everythingDo not waist time writing code you know is wrong because you are afraid to ask

5. S.O.L.I.D Principles of Software Development

6. The S.O.L.I.D Principles of Software Development • SOLID was introduced by Robert C. Martin in the an article called the “Principles of Object Oriented Design” in the early 2000s • http://www.objectmentor.com/omTeam/martin_r.html • Agile Software Development • You Aren’t Gonna Need It (YAGNI) • Keep It Simple, Stupid (KISS) • Vertical Slice • Big Ball of Mud

7. SRP the “S” in S.O.L.I.D

8. Single Responsibility Principle (SRP) “There should never be more than one reason for a class to change.” Each responsibility should be a separate class, because each responsibility is an axis of change. A class should have one, and only one, reason to change. If a change to the business rules causes a class to change, then a change to the database schema, GUI, report format, or any other segment of the system should not force that class to change. • Axis of Change • Separation of Concern • Test-Driven Development (TDD) • Logical Separation of Namespaces And Assemblies. Robots on an assembly line are streamlined for the individual tasks they preform. This makes maintaining, upgrading, and replacing them easier and less expensive.

9. Single Responsibility Principle (SRP)

10. Static Helper Classes and Extension Methods As Helper As Extension

11. OCP the “O” in S.O.L.I.D

12. Open/Closed Principle (OCP) « software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.” • Meyer's Open/Closed Principle • Implementation of a class should only be modified to correct errors. • Changes or new features require that a different class be created (Interfaces) • Polymorphic Open/Closed Principle • All member variables should be private. • Global variables should be avoided. -Bertrand Meyer Objects should be design in such a way that it is easy to extend them without modifying them. You can easily change the lens of most SLR cameras without having to saw off the old lens and weld on a new one. You can add filters to most SLR camera lens by just screwing them on.

13. Change Happens “All systems change during their life cycles. This must be borne in mind when developing systems expected to last longer than the first version.” - Ivar Jacobson

14. All member variables should be private Instead of Public Fields Use Properties or Properties with Private Backing Fields

15. Method parameters should be interfaces not specific classes Using interfaces for parameters, properties, and variables whenever possible helps keep them “ Open” to extension and also helps keep the classes “Closed” to modification because the abstraction.

16. LSP the “L” in S.O.L.I.D

17. Liskov Substitution Principle (LSP) “Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program” “Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.” • Polymorphism • Test-Driven Development (TDD) • Avoid Run-Time Type Information (RTTI) As you extend objects the original functionality of the elements that makeup the object should not change. Any Base 10 calculator should produce a result of “4” when you press “2+2=“ regardless of the age or sophistication of the device. The original functionality of objects should preserved as you build on them.

18. Avoid Run-Time Type Information (RTTI) Sometimes using RTTI is unavoidable

19. Objects should be replaceable with subtypes When overriding a class you must be carful that the way you extend it does not cause it to no longer work in place of the classit inherited from

20. ISP the “I” in S.O.L.I.D

21. Interface Segregation Principle (ISP) • “Many client specific interfaces are better than one general purpose interface” • “Clients should not be forced to depend upon interfaces that they do not use.” • Design by contract (DbC) / Design to Interfaces • Test-Driven Development (TDD) It is difficult to use a device that produces “HDMI Audio/Video” with a “Digital Optical” sound player.

22. Abstract classes using interfaces Use interfaces.  Even where you don't need them yet. Steve Rowe http://blogs.msdn.com/b/steverowe/archive/2008/01/21/design-to-interfaces.aspx

23. Many specific interfaces are better one general

24. Clients should not depend upon interfaces that they do not use Each interface should specifically describe only what is needed and nothing more.

25. DIP the “D” in S.O.L.I.D

26. Dependency Inversion Principle (DIP) “High level modules should not depend upon low level modules. both should depend upon abstractions.” “Abstractions should not depend upon details. Details should depend upon abstractions.” • Loose Coupling • Dependency Injection / Inversion of Control Screwdriver bits do not care what brand or type of Slotted Screwdriver they are used with.

27. Dependency Injection / Inversion of Control

28. High & low level modules should depend upon abstractions No reference or dependency to a specific Data access technology should ever exist outside of the Data Access Assembly this includesADO.net, LinqToSql, EF4, Nhibernate….. Only Interfaces and POCO (Plain Old Clr Objects) should be referenced between assemblies and primarily they should reference an interface.

29. S.O.L.I.D Principles of Software Development

30. S.O.L.I.D Principles of Software Development The first sprint that involves actual programming should be a single vertical slice that demonstrates scope and strategy of the entire application from top to bottom.

31. Highly Recommended Books http://www.amazon.com/Professional-ASP-NET-Design-Patterns-Millett/dp/0470292784/ http://www.amazon.com/UML-Java-Programmers-Robert-Martin/dp/0131428489/ http://www.amazon.com/UML-Java-Programmers-Robert-Martin/dp/0131428489/ http://www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258 Professional ASP.NET Design Patterns Elements of Reusable Object-Oriented Software UML for Java(TM) Programmers Agile Principles, Patterns, and Practices in C#

32. Thought Leadership