The document summarizes strategies for combating software entropy through principles of software design such as the single responsibility principle, open/closed principle, and dependency inversion principle. It provides examples of how to refactor code to adhere to these principles, make the software more extensible and resilient to changes. Metrics for software design like afferent/efferent couplings and instability are also discussed to measure how well code adheres to these design best practices.
Aspect-Oriented Programming (AOP) complements Object-Oriented Programming (OOP) by providing another way of thinking about program structure. The key unit of modularity in OOP is the class, whereas in AOP the unit of modularity is the aspect. Aspects enable the modularization of concerns such as transaction management that cut across multiple types and objects. (Such concerns are often termed crosscutting concerns in AOP literature.)
One of the key components of Spring is the AOP framework. While the Spring IoC container does not depend on AOP, meaning you do not need to use AOP if you don't want to, AOP complements Spring IoC to provide a very capable middleware solution.
[4DEV] Bartosz Sokół - Functional developer in object oriented world - how F#...PROIDEA
Object-oriented programming languages have been here for decades, helping millions of developers to deliver (sort of) working software. Still, after many years, we still struggle with things like nulls and exceptions, which make our applications crash in most unexpected ways. So I have taken a challenge - can you use object-oriented language (C#) and write code in a way that those issues are almost gone? I will show how to leverage lessons learned from functional programming to make our applications more bulletproof - and fun to write as well!
Aspect-Oriented Programming (AOP) complements Object-Oriented Programming (OOP) by providing another way of thinking about program structure. The key unit of modularity in OOP is the class, whereas in AOP the unit of modularity is the aspect. Aspects enable the modularization of concerns such as transaction management that cut across multiple types and objects. (Such concerns are often termed crosscutting concerns in AOP literature.)
One of the key components of Spring is the AOP framework. While the Spring IoC container does not depend on AOP, meaning you do not need to use AOP if you don't want to, AOP complements Spring IoC to provide a very capable middleware solution.
[4DEV] Bartosz Sokół - Functional developer in object oriented world - how F#...PROIDEA
Object-oriented programming languages have been here for decades, helping millions of developers to deliver (sort of) working software. Still, after many years, we still struggle with things like nulls and exceptions, which make our applications crash in most unexpected ways. So I have taken a challenge - can you use object-oriented language (C#) and write code in a way that those issues are almost gone? I will show how to leverage lessons learned from functional programming to make our applications more bulletproof - and fun to write as well!
http://www.jiowa.de/download.html
Jiowa Code Generation Framework and its Template Engine:
Key features:
- compile-time safety for your templates,
- full control of code generation via Java,
- very effective and comprehensible template notation,
- strict separation of code (Java generator) & design (template),
- templates do not carry any model specific information
==> completely re-usable across different projects,
- supports any type of model for which an API exists,
- supports each IDE (no plug-in necessary),
- easily extensible via Java,
- no polyglot programming,
- it is possible to dynamically change the template notation symbols if suitable for the target platform (Java, C++, C#, XML, ...),
- supports protected regions,
- syntax highlighting for target platform instead for template notation (templates are very easy to read).
Adam Culp will talk about refactoring code. (The practice of altering code to make it cleaner, simpler, and sometimes faster, while not sacrificing functionality.) We all hate to do it, but it is a necessary evil. So lets talk about how to do it better. Adam will discuss: When to refactor. How to refactor. Why to refactor. How a refactor can help us write better code in the future. A common methodology and steps to follow while refactoring. Resources to help us all on our refactor journey.
Architecture DSLs are a useful tool to capture the cornerstones of platform or product line architectures. In addition, interesting analyses can be performed on the models, and much of the infrastructure and configuration code can be generated. On the flip side, these DSLs themselves must be architected consciously: while many architectural abstractions are specific to any given platform or product line, many other aspects are generic and hence can be reused for several architecture DSLs. In this talk I trace how my thinking on architecture modeling has changed over time, and how this is reflected in the architecture DSLs I have built (or helped to build), and how evolving tools have made these changes possible.
Aspect-oriented programming, or AOP, is a programming technique that allows programmers to modularize crosscutting concerns
It is often defined as a programming technique that promotes separation of crosscutting concerns with in a software system
concerns :
A concern is a particular issue, concept, or area of interest for an application: typically, a goal the application must meet
Refactoring: Improve the design of existing codeValerio Maggio
Refactoring: Improve the design of existing code
Software Engineering class on main refactoring techniques and bad smells reported in the famous Fawler's book on this topic!
Evolving a Clean, Pragmatic Architecture - A Craftsman's GuideVictor Rentea
Talk given at Devoxx Belgium 2019.
===== Abstract =====
Are you in a mood for a brainstorm? Join this critical review of the major decisions taken in a typical enterprise application architecture and learn to balance pragmatism with your design goals. Find out how to do just-in-time design to keep as many use-cases as simple as possible.
The core purpose of this presentation is to learn to strike a **balance between pragmatism and maintainability** in your design. Without continuous refactoring, a simple design will inevitably degenerate into a Big Ball of Mud, under the assault of the new features and bugfixes.
On the other hand, the very highly-factored code can burden the take-off of the development and end up freezing the mindset in some rigid upfront design.
The end goal of this talk is to challenge you to rethink critically the architecture of your systems and seek ways to simplify it to match your actual needs, with a pragmatic mindset. "Architecture is the art of postponing decisions", said Uncle Bob.
This talk takes this idea further and explains an optimal mindset about designing enterprise applications: Evolving (Continuously Refactoring) a Pragmatic (Simple), Clean (aka Onion) Architecture, aiming to provide Developer Safety™️ and Comfort™️.
It’s the philosophy that Victor distilled over the past 5 years, designing and implementing 9 applications as IBM Lead Architect, and delivering training and advises to many other companies.
You’ll learn how to break data into pieces (Fit Entities, Value Objects, Data Transfer Objects), how to keep the logic simple (Facades, Domain Services, logic extraction patterns, Mappers, AOP), layering to enforce boundaries (keeping DTOs out of your logic, Dependency Inversion Principle), and many more, all in a dynamic, interactive and extremely entertaining session.
Every project has a development standard.
Sometimes the standard is “if it was hard to write, it should be hard to maintain.”
Developing, and following, a corporate Best Practices standard will lead to continuity, maintainability, robustness, and pride.
http://www.jiowa.de/download.html
Jiowa Code Generation Framework and its Template Engine:
Key features:
- compile-time safety for your templates,
- full control of code generation via Java,
- very effective and comprehensible template notation,
- strict separation of code (Java generator) & design (template),
- templates do not carry any model specific information
==> completely re-usable across different projects,
- supports any type of model for which an API exists,
- supports each IDE (no plug-in necessary),
- easily extensible via Java,
- no polyglot programming,
- it is possible to dynamically change the template notation symbols if suitable for the target platform (Java, C++, C#, XML, ...),
- supports protected regions,
- syntax highlighting for target platform instead for template notation (templates are very easy to read).
Adam Culp will talk about refactoring code. (The practice of altering code to make it cleaner, simpler, and sometimes faster, while not sacrificing functionality.) We all hate to do it, but it is a necessary evil. So lets talk about how to do it better. Adam will discuss: When to refactor. How to refactor. Why to refactor. How a refactor can help us write better code in the future. A common methodology and steps to follow while refactoring. Resources to help us all on our refactor journey.
Architecture DSLs are a useful tool to capture the cornerstones of platform or product line architectures. In addition, interesting analyses can be performed on the models, and much of the infrastructure and configuration code can be generated. On the flip side, these DSLs themselves must be architected consciously: while many architectural abstractions are specific to any given platform or product line, many other aspects are generic and hence can be reused for several architecture DSLs. In this talk I trace how my thinking on architecture modeling has changed over time, and how this is reflected in the architecture DSLs I have built (or helped to build), and how evolving tools have made these changes possible.
Aspect-oriented programming, or AOP, is a programming technique that allows programmers to modularize crosscutting concerns
It is often defined as a programming technique that promotes separation of crosscutting concerns with in a software system
concerns :
A concern is a particular issue, concept, or area of interest for an application: typically, a goal the application must meet
Refactoring: Improve the design of existing codeValerio Maggio
Refactoring: Improve the design of existing code
Software Engineering class on main refactoring techniques and bad smells reported in the famous Fawler's book on this topic!
Evolving a Clean, Pragmatic Architecture - A Craftsman's GuideVictor Rentea
Talk given at Devoxx Belgium 2019.
===== Abstract =====
Are you in a mood for a brainstorm? Join this critical review of the major decisions taken in a typical enterprise application architecture and learn to balance pragmatism with your design goals. Find out how to do just-in-time design to keep as many use-cases as simple as possible.
The core purpose of this presentation is to learn to strike a **balance between pragmatism and maintainability** in your design. Without continuous refactoring, a simple design will inevitably degenerate into a Big Ball of Mud, under the assault of the new features and bugfixes.
On the other hand, the very highly-factored code can burden the take-off of the development and end up freezing the mindset in some rigid upfront design.
The end goal of this talk is to challenge you to rethink critically the architecture of your systems and seek ways to simplify it to match your actual needs, with a pragmatic mindset. "Architecture is the art of postponing decisions", said Uncle Bob.
This talk takes this idea further and explains an optimal mindset about designing enterprise applications: Evolving (Continuously Refactoring) a Pragmatic (Simple), Clean (aka Onion) Architecture, aiming to provide Developer Safety™️ and Comfort™️.
It’s the philosophy that Victor distilled over the past 5 years, designing and implementing 9 applications as IBM Lead Architect, and delivering training and advises to many other companies.
You’ll learn how to break data into pieces (Fit Entities, Value Objects, Data Transfer Objects), how to keep the logic simple (Facades, Domain Services, logic extraction patterns, Mappers, AOP), layering to enforce boundaries (keeping DTOs out of your logic, Dependency Inversion Principle), and many more, all in a dynamic, interactive and extremely entertaining session.
Every project has a development standard.
Sometimes the standard is “if it was hard to write, it should be hard to maintain.”
Developing, and following, a corporate Best Practices standard will lead to continuity, maintainability, robustness, and pride.
Most developers have the responsibility of working with an existing codebase that is not testable. In this session, you will learn several techniques to refactoring non testable code. In addition, unit tests will be added and executed as a part of an automated test suite. The associated code/project is here: https://github.com/rightincode/RefactoringToTestableCode
Any structure expected to stand the test of time and change needs a strong foundation! Software is no exception. Engineering your code to grow in a stable and effective way is critical to your ability to rapidly meet the growing demands of users, new features, technologies, and platform capabilities. Join us to obtain architect-level design patterns for use in your Apex code to keep it well factored, easy to maintain, and in line with platform best practices. You'll follow a Force.com interpretation of Martin Fowler's Enterprise Architecture Application patterns, and the practice of Separation of Concerns.
The is from the book Agile Development in .NET by Dan Hermes. Most Agile methodologies used in .NET shops nationwide are variations of Scrum and Extreme Programming(XP). This booklet covers these tools and techniques: Test-driven Development (TDD), Behavior-driven Development (BDD), Continuous Integration (CI), and Refactoring to Patterns. The QuickNotes series covers relevant topics in software development to provide the reader with a swift overview of important trends, terms, and concepts. This book is available at Amazon.com.
Most dev teams have a very simple conception of software architecture. They start with a database, a user interface, and add layers of (DRY) mess between the two. Then they have a performance problem so they add memcache and mongodb (Now we're webscale!).
Months or years later, releasing new features in production gets harder and riskier: it's time for a rewrite. Let's use AnguNodeMvcDoop to solve all our maintainability issues! And the cycle starts over...
In this talk we'll see that software architecture is not defined by the technologies you use but by the high level principles you set. We'll see what really matters to make your information system maintainable and how to get there progressively!
O365 Saturday - Deepdive SharePoint Client Side RenderingRiwut Libinuko
Deepdive to SharePoint Client Side Rendering.
This presentation includes demo that you can follow on Youtube channel https://www.youtube.com/channel/UC_qdk2Sv-qKDkXGZolQZSew.
Source code for this presentation is also available through GitHub https://github.com/cakriwut/Business365.CSR
ChatGPT and Beyond - Elevating DevOps ProductivityVictorSzoltysek
In the dynamic field of DevOps, the quest for efficiency and productivity is endless. This talk introduces a revolutionary toolkit: Large Language Models (LLMs), including ChatGPT, Gemini, and Claude, extending far beyond traditional coding assistance. We'll explore how LLMs can automate not just code generation, but also transform day-to-day operations such as crafting compelling cover letters for TPS reports, streamlining client communications, and architecting innovative DevOps solutions. Attendees will learn effective prompting strategies and examine real-life use cases, demonstrating LLMs' potential to redefine productivity in the DevOps landscape. Join us to discover how to harness the power of LLMs for a comprehensive productivity boost across your DevOps activities.
So You Just Inherited a $Legacy Application...Joe Ferguson
You were just handed the keys to a new repo. Your first glance over the code base causes the fearful "LEGACY" word to ring in your head. HAVE NO FEAR! I'll share the techniques I've learned after working on several legacy codebases to help update that old code to the current PHP generation. We'll cover triaging the old code base, writing tests to make sure you don't break anything, and how to modernize your old code base!
Similar to C:\Fakepath\Combating Software Entropy 2 (20)
2. ARC202 - Combating Software Entropy with Design Patterns and Principles Hammad Rajjoub Solutions Architect @ Infusion Microsoft MVP
3. Cogito, Ergo , Sum Microsoft MVP – Connected Systems (5+ yrs) Solutions Architect at Infusion The coolest company in town Develop. Design. Venture. Join us! Speaker, Author & Community Leader I do: Blog + Twitter + PodCast Bing me http://www.bing.com/search?q=hammadrajjoub
4. Agenda Why is Software Complex? What is bad design? How to Fix it? Summary References QnA
5. Why is Software Complex Writing new software Mandated to develop new systems Generally from scratch But still mostly relying on existing libraries and frameworks Real-world problems are sometimes complex Modifying Existing Software Find that ‘bug’ and ‘fix’ it Add a new exciting feature Review and refactor to a better design
7. Bad design is... Hard to change! A single change break lots of other code Rigid Fragile Can’t be ‘extended’ Immobile
8. How to fix it? Using design principles and practices The Single Responsibility Principle The Open Closed Principle Liskov Substitution Principle Dependency Inversion Principle Using Software Design Metrics And yes a whole lot of refactoring
9. Single Responsibility Principle None but Buddha himself must take the responsibility of giving out occult secrets... E. Cobham Brewer 1810–1897. Dictionary of Phrase and Fable. 1898. SRP
10. The Single responsibility principal "A responsibility is a reason to change, a class or module should have one, and only one, reason to change."
11. The Single Responsibility Principal Responsibility is a ‘Reason for change’ Each responsibility is an axis of change There should never be more than one reason for a class to change Dijkstra’s SoC: Separation of Concerns This helps us evaluate a class ‘s exposure to change
14. Counterparty Validator – Iter 1 internal class BusinessPartnerValidator { public void AssertValid(Trade t) { varsql = "SELECT COUNT(*) FROM BusinessPartner WHERE name=@Name"; using (varconn = CreateOpenConnection()) { varcmd = new SqlCommand(sql, conn); cmd.Parameters.Add("@Name", SqlDbType.VarChar); cmd.Parameters["@name"].Value = t.BusinessPartnerName; var count = (Int32) cmd.ExecuteScalar(); if (count != 1) throw new InvalidBusinessPartyException(t.BusinessPartyName); } } ... Where is the business logic? Hidden by database code.
15. BusinessPartyValidator – Iter 2 internal class BusinessPartnerValidator { private readonlyBusinessPartnerValidatorbusinessPartnersource; public BusinessPartyValidator(BusinessPartnerSourceBusinessPartySource) { this.businessPartnerSource = BusinessPartnerSource; } public void AssertValid(Trade t) { if (BusinessPartnerSource.FindByName(t.BusinessPartnerSource) == null) throw new InvalidBusinessPartnerException(t.BusinessPartnerName); } } BusinessPartyValidator now has a single responsibility
18. The Open Closed Principle Realise that generally systems outlive their expected timelines All software entities should be closed for change and opened for extension Your design modules should never change You should just extend the behaviour
19. Liskov Substitution Principle There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened. Douglas Adams (1952 - 2001)
20. The Liskov substitution principal “Functions that reference a base class must be able to use objects of derived classes without knowing it."
25. Dependency Inversion It may be that the old astrologers had the truth exactly reversed, when they believed that the stars controlled the destinies of men. The time may come when men control the destinies of stars. Arthur C. Clarke (1917 - ), First on the Moon, 1970
30. DI & IoC IoC is key part of Frameworks Interfaces, Closures & Events Hollywood Principal (Don’t call us, We will call you) IoC is a very general name and hence the Dependency Injection* Suits Test Driven Development Number of dependencies indicate stability *http://martinfowler.com/articles/injection.htm l
32. Some Key Design Metrics - Ca Afferent Couplings - Ca The number of other packages that depend upon classes within the package is an indicator of the package's responsibility. BPackage APackage Package Class
33. Some Key Design Metrics Efferent Couplings – Ce The number of other packages that the classes in the package depend upon is an indicator of the package's independence. BPackage APackage Package Class
34. Some Key Design Metrics Instability – I = Ce / (Ce + Ca) This metric is an indicator of the package's resilience to change. The range for this metric is 0 to 1, 0 indicating a completely stable package 1 indicating a completely instable package.
35. Use Visual Studio Code Metrics Maintainability Index Cyclomatic Complexity Depth of Inheritance Class Coupling Lines of Code Code Coverage
37. What else can I do? ISP: Interface Segregation Principle Avoid fat interfaces REP: The Release Reuse Equivalency Principle The granule of reuse is the granule of release. CCP: The Common Closure Principle Classes that change together are packaged together. CRP: The Common Reuse Principle Classes that are used together are packaged together. SDP: The Stable Dependencies Principle Depend in the direction of stability.
38. Strategic Closure No significant program can be 100% closed Closures cant be complete Closures must be ‘Strategic’ Stability metrics can indicate hotpots Designer must choose the changes against which her design should be closed
39. Summary Remember your application will outlive your expectation Follow these design principles Be Agile! Refactor ++ Use Code Metrics
40. References Uncle Bob http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Agile Principles, Patterns and Practices in C# Martin Fowler’s Blog: http://martinfowler.com/bliki/
42. Required Slide Speakers, TechEd 2010 is not producing a DVD. Please announce that attendees can access session recordings at TechEd Online. www.microsoft.com/teched Sessions On-Demand & Community www.microsoft.com/learning Microsoft Certification & Training Resources http://microsoft.com/technet Resources for IT Professionals http://microsoft.com/msdn Resources for Developers Resources
In this session we are going to talk about how to tackle inherently complex nature of a software. I am going to show you 'most important principles, tools and techniques you can use to 'combat software entropy'. Together, we will gain an insight in to the heart of the software design. We will talk about the heuristics associated with the software design and architectural patterns and practices. Intended audience of this session in-general includes all the stake holders in software development process i.e. from Developer to Architect to Project and Program Manager and even CTOs and CIOs. However I have focused specially on targeting Software and Solutions Architects, i.e. individuals or teams responsible for the overall design and architecture of the solution. So, if you consider yourself as a stake holder in Software development process then you have come to the right place. Before I proceed further I would like to request you that feel free to participate in the discussion. I am very keen to hear from you and answer your questions as we walkthrough the slides. However if we run out of time, which tends to happen a lot :), then I should be available at the community lounge to answer your questions.
Lets get rolling then, shall we?Heres an agenda:
Using the term software in its broadest possible sense.There are two broad categories that software development falls into. First and the foremost is the 'Writing new code' classification. - Use-Case 1: Writing new code In this scenario we are mandated to develop new systems, mostly from the scratch but usually using some existing pieces of code e.g. Class libraries, frameworks, services etc etc. In this scenario we have more freedom and control over design and we can implement patterns and practices the way we would like it to be. Generally speaking, we are trying to solve real world problems, like business automation, weather forecasting, algorithmic trading etc etc. There is an inherent disconnect between the real world and our software programming model and that very fact is at the heart of software complexity. - Use-Case 2: Now, how many time do we get to write new software? Lets do a show of hands here. I am guessing that most of the time we end up working on existing code bases, where we have to - find that tormenting bug and fix it. - add a new exciting feature - and if you are lucky or unlucky like me then review it and refactor it so that i can handle change in a better way This scenario is complex because. 1- We generally find it difficult to understand some one else’s code 2- We believe ‘we would have done it in a different/better way’ 3- 2 is true even if we ourselves were the author of that code few years back
As Architects how do we identify the good, the bad and the ugly of Software Design.For that perhaps we need some metrics such that we can always measure and identify which side of the fence our software belongs to.
How many times have you come across the code that you can qualify as a ‘bad design’? Or atlease and most commonly would have said, That’s not the way I would have done it.Before we move on. Lets agree on what's a bad design? Ok it’s a bit difficult to be exact about the metrics of bad design in software. But lets agree on some common aspects of bad design.Rigidity FragilityImmobilityCode that’s hard to change is bad… Rigid code is bad!Code that has lots of ripple effects.. A single change break lots of other code. Fragile code is bad!Code that cant be re-used… Code that cant be ‘extended’ is bad.. Immobile
Now that we know what the bad design is. Lets see how we can fix it? Would you be interested in identifying the principles and practices that will help you make sure that your design, architecture and code is not rigid, your solutions are not fragile and your frameworks are not immobile.Wouldn’t you like to have flexibility in your design, resiliency in your architecture and agility in your frameworks such that they can adapt to the ever changing business requirements.Lets drill down to each of these principles and see what can we do to fix our bad design.
If a class has more then one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’ ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.
What is responsibility? … It is a reason for change.We should consider each responsibility as an axis of change. The more axis of changes the more dimension effected.As a right hand rule, there should never be more than one reason for a class to change.The term separation of concerns was probably coined by Edsger W. Dijkstra in his 1974 paper "On the role of scientific thought"[1].Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained --on the contrary!-- by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focusing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.
BusinessPartner
Example do demonstrate role based interfaces IVE examples
Mention ronald’s session here.
Classes should have a single responsibility or jobDevelopers should have that job in mind when they work on a classA developer should easily be able to write a block comment at the top of a class identifying its job.That comment should not have the word AND in it.As architects and leads we should be able to ask this question.. Whats the job of this class? a developer should always have this job in mind use intuitive and simple names remember! no conjunctions (ANDS)
Add an example
- “All systems change during their life cycles. This must beborne in mind when developing systems expected to last longer than the first version.” - SOFTWARE ENTITIES(CLASSES,MODULES,FUNCTIONS,ETC.) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION- Bertrand Myers in 1988It says that you should design modules that never change . When requirements change, you extend the behaviour of such modules by adding new code, not by changing old code that already works.When a single change to a program results in a cascade of changes to dependent modules,that program exhibits the undesirable attributes that we have come to associate with “bad”design. The program becomes fragile, rigid, unpredictable and unreusable. The openclosedprinciple attacks this in a very straightforward way. It says that you should designmodules that never change. When requirements change, you extend the behavior of suchmodules by adding new code, not by changing old code that already works.The modules that follow OCP have the following two characteristics:=-1. They are “Open For Extension”.This means that the behaviour of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.2. They are “Closed for Modification”.The source code of such a module is inviolate. No one is allowed to make source code changes to it.
Composabilityvsinheritence
Define degenrate methodsShow an example here.
*Uml compatible.
- Inversion of control is the basic feature of any framework in a way that frameworks are differentiated from libraries by offering the support for ‘Hollywood Principal’ (‘Don’t call us , we will call you’)- One important characteristic of a framework is that the methods defined by the user to tailor the framework will often be called from within the framework itself, rather than from the user's application code. The framework often plays the role of the main program in coordinating and sequencing application activity. This inversion of control gives frameworks the power to serve as extensible skeletons. The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application.--Ralph Johnson and Brian Foote
Afferent Couplings (Ca): The number of other packages that depend upon classes within the package is an indicator of the package's responsibility. -------------Show how visual studio does it.
Efferent Couplings (Ce): The number of other packages that the classes in the package depend upon is an indicator of the package's independence.
Instability (I): The ratio of efferent coupling (Ce) to total coupling (Ce + Ca) such that I = Ce / (Ce + Ca). This metric is an indicator of the package's resilience to change. The range for this metric is 0 to 1, with I=0 indicating a completely stable package and I=1 indicating a completely instable package.
MI: http://blogs.msdn.com/fxcop/archive/2007/11/20/maintainability-index-range-and-meaning.aspx 0-100 range.20-100 is green.The maintainability index has been re-set to lie between 0 and 100. How and why was this done?The metric originally was calculated as follows (based on the work in Carnegie Mellon University although we modified the Halstead Volume calculation a little since we don't include comments anywhere in our calculation): Maintainability Index = 171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code)This meant that it ranged from 171 to an unbounded negative number. We noticed that as code tended toward 0 it was clearly hard to maintain code and the difference between code at 0 and some negative value was not useful. I'll post some tech ed sample code showing very low maintainability or you can try on your own code to verify. As a result of the decreasing usefulness of the negative numbers and a desire to keep the metric as clear as possible we decided to treat all 0 or less indexes as 0 and then re-base the 171 or less range to be from 0 to 100. Thus, the formula we use is:Maintainability Index = MAX(0,(171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code))*100 / 171)On top of that we decided to be conservative with the thresholds. The desire was that if the index showed red then we would be saying with a high degree of confidence that there was an issue with the code. This gave us the following thresholds (as mentioned in this blog previously):For the thresholds we decided to break down this 0-100 range 80-20 so that we kept the noise level low and only flagged code that was really suspicious. We have:0-9 = Red 10-19 = Yellow 20-100 = Green-----------------------------------------------------------------------------------------------------------------------------------------------CC: http://en.wikipedia.org/wiki/Cyclomatic_complexityCyclomatic complexity is computed using the control flow graph of the program: the nodes of the graph correspond to indivisible groups of commands of a program, and a directed edge connects two nodes if the second command might be executed immediately after the first command. Cyclomatic complexity may also be applied to individual functions, modules, methods or classes within a program.Limiting complexity during developmentOne of McCabe's original applications was to limit the complexity of routines during program development; he recommended that programmers should count the complexity of the modules they are developing, and split them into smaller modules whenever the cyclomatic complexity of the module exceeded 10.[2] This practice was adopted by the NIST Structured Testing methodology, with an observation that since McCabe's original publication, the figure of 10 had received substantial corroborating evidence, but that in some circumstances it may be appropriate to relax the restriction and permit modules with a complexity as high as 15. As the methodology acknowledged that there were occasional reasons for going beyond the agreed-upon limit, it phrased its recommendation as: "For each module, either limit cyclomatic complexity to [the agreed-upon limit] or provide a written explanation of why the limit was exceeded."[5]
Since closure cannot be complete, it must be strategic. That is, the designer must choose the kinds of changes against which to close his design. This takes a certain amount of prescience derived from experience. The experienced designer knows the users and the industry well enough to judge the probability of different kinds of changes. He then makes sure that the open-closed principle is invoked for the most probable changes.So in a way its not just the language and the compiler and the ide itself. But the effort on the part of the designer to think and re think about these aspects and then do/refactor the design
We believe we have given you an insight into the heart of the software complexity and stability in the face of change.Now, not only you can judge your design using these principals.you can measure them quality of your design using software design metrics. What are those metrics and how do they work is beyond the scope of this discussion but definitely worth looking at.Code metrics:Maintainability IndexCyclomatic Complexity Depth of InheritenceClass Coupling http://msdn.microsoft.com/en-us/library/bb385914(VS.100).aspx VS has it,