Jonathan Crossland's Talkware

&

On the concept of contracts and contracts, I think we need "interface phasing". Having a phased relationship between two parties.
It is imperative that objects and at a higher level, an Application, can change the way they interact by who or what is accessing them.

 

An object should present itself differently to different audiences. Imagine a developer seeing a specific interface, but not a user, or IDE vs developer. Its not role based, because it could be different per application to application communication, although a similar effect can be achieved.

The concept is simple.

I think that coding today suffers from

• Repetitive nature of structural elements: for example: creation of large Object Models, classes, properties, collections and so on.

• Creating Object models with no separation of Context or concerns. I want an object to 'share' code, but for different reasons. Cross-Cutting. Yes, I can create a new object and share code, but that's not always the answer. Imagine two object models, where one is a Facade of the first. I want to simply map the one to the other, not create the entire structure for it again.

• Different ways of extending components. Different ways of creating add-ins, Custom B2B, Adaptors, Bridge patterns etc. It can all be made easier, if we used a "Global extension object system"

• The 'under the hood' 'abstractions, keep changing - not for the better or necessarily for the worse, but for no distinct benefit.

• Contractinitis - Nothing works unless its all explicit. In .NET, can't call the web service with your Person Object, cause its not the same namespace etc.

 

Create automatic and dynamic proxy layers based on metadata and intention of communication. The code is then 'assembled' and made ready for the communication. The code is assembled from existing non contextual code that can fit into a common proxy container and interact.

On a simple level, imagine, you create SOA like methods, stateless and they are formulated by the runtime into a new object that looks like the one required.

This is not the complete answer, but we really need to get to 'smarter relationships' rather than contracts.

See Lack of MetaData on code and .NET Framework libraries

Read Evolution, Architecture, and Metamorphosis - A great piece of work.

 

Tags:

Our software contract world is the accepted norm, and of course we have come a long way with the philosophy as its been the corner stone of our development languages and platforms for how long.
However, other concepts have also existed. In the seemingly archaic world of top down programming, there were no interface or object-oriented contracts. Instead a form of duck-typing and vtable calls ruled the day or even worse pointers and addresses.
Today the concepts of interface and implementation etc are sometimes lost on the new generation of developers, as its so seamless today.
However, I think that if you look at the real world, communication is lossy, and not defined by the same kind of rules.

In the real world we kind of just make sure there is someone around, or get the person focused on us, then we talk. The receiver understands or does not understand, or does not listen, or hears and acts on all that is said. In the real world, not every communication has "roger", "over and out". There are obvious benefits to having it sometimes, but a real pain in other situations.

The interaction of software frameworks is a real candidate for a more lossy communication, or a Communication Agent, put in software terms. The ability to translate messages from "intention to result" is imperative.

When a call is made to string GetUserName() or string getNameOfUser, the intention is the same, but in our current forms of software architecture, a human would have to use a design pattern, Adaptor, Bridge or whichever suited to accomplish it, when clearly, to our human eyes, the function could well be identical but for name.

A new kind of Interface Definition language is needed to declare intentions of interfaces, and allow a mapping agent to successfully arbitrate a result.

Tags:

... you know when you have it, or not?

You see it written in code samples: No warranty, please take care if you use in production environment. This is not production code, but what does production code really mean?

Firstly production code can be any code that is in use. But that does not refer anything about quality. Just because software is on the shelf, does not mean its good quality.
Production code must have some sort of quality level.

Amusingly the DSDM pocket book, (Atern) says that "it must be good enough" - which makes me laugh, then cry.

Quality is subjective yes, and quality costs money. So what should production code be?

The following is a list of heuristics for referring to code as production code.

• More than 40% of your application has Unit Tests
• At least 3 or more people have spent time actively seeking bugs, for longer than 30% of the time it took to originally write.
• At least 3 or more people have been actively seeking bugs, in at least 5 different configurations/environments.You have mixed the environment (different server, different database name, altered culture/region, etc).
• Bugs have been solved with SolvingDesign (A lasting solve)
• Code Regression is reduced, practically to a stand-still. A ratio of 50 bugs solved per 1 reintroduced is a good ratio. 5 bugs solved for 1 reintroduced is a terrible ratio.
• Users have used the code for at least 40% of the development time taken, reporting bugs, and the system recompiled and redeployed at 5 times during this period. (preferably at intervals, so input can be recalculated)

Influence that will present itself, and cause you into thinking its production code, before its not.

• Deadline and other pressures
• Reactionary mindset, rather than pre-emptive
• Bad company software creation intelligence (what else can you call it?)
• Human traits, inexperience, carelessness etc

Tags: methodology, production, quality

Although .NET Reflecton offers a decent look at the Types you build, it is pretty generic in its offering. For example, it does not yet provide us with capabilities to control and secure how Reflection can inspect our Types. If you do not want a Type to be Instantiated via Reflection, or if you would like to restrict certain Types from being visible at all. Further there is no idea for extension or change. One cannot simply plug into Reflection and override behaviour.

High abstractions and higher flexibility

Many more wrappers are needed, at a higher level, which would sit on top of .NET Reflection. For example, architectural dependencies. Agile mechanisms, if code had enough metadata attached, one could alter the code via reflection/refactoring in a much more dynamic way. Consider the following two web service methods in two different companies.

  public class PersonService
    {
        public void AddPerson(string lastname, string firstname, 
            string birthdate)
        {
        }
    }

    public class PersonWebService
    {
        public void AddNew(string firstname, string surname)
        {
        }
    }

You can see that they are completely different contracts. Interface and contract speaking they are like apples and sand. However, to your mapping, calculating, schema, metadata, tagging and understanding brain, its the same thing.

What we need, is to remove ourselves from Contracts to something more like guidelines.

  public class PersonService
    {
        [Operation(Schema:Person, "Add")]
        public void AddPerson([schema(LastName)]string lastname, 
             [schema(FirstName)]string firstname, 
             [schema(DateOfBirth)] string birthdate)
        {
        }
    }

    public class PersonWebService
    {
        [Operation(Schema:Person, "Add")]
        public void AddNew([schema(FirstName)]string firstname, 
             [schema(LastName)]string surname)
        {
        }
    }

Tags: design patterns, frameworks, reflection, metadata

Not sure if there is a Design Pattern relating to this kind of need in another pattern catalogue, but it seemed simple enough to reverse the GOF composite. A class with a collection of leaves, that iterate, recurse its way up to the root. This needs work in terms of combining or actually making a variation on the composite. I think that this is perhaps only a .1 degree of separation.

Problem

You have a list of Items, that may or may not be related. There may be 1 or more trees. You have a bag of unsorted or related objects as a signle array. You need to maintain a complete list of leaves, but also need the relationship/heirarchy to become apparent. You want to express the heirarchy in a Composite Pattern, but it would exclude certain leaves has it has no part in the particular root that the composite gets built on.

Context

You need a collection of leaves, from across the composite tree. You need to have access to the parent and/or recurse to the root.

Types are stripped from its branches.

 

Structure

A class that works with a collection of leaf classes, that each point to it's parent. In effect a composite in reverse. Keep all the leaf objects in a collection and build the heirarchy from the bottom up.




One of the main reasons behind this is multiple paths to a set endpoint. The root becomes the set endpoint where by we can plot a course from a leaf. The Leaf though is where we start from and full knowledge of all leaves should be known at the outset. 

By adding a Parent on the Composite (GoF), you can achieve a similar result, but you will not have a flat list of leaves.

Tags: design patterns, composite, reverse composite

Eventually Interfaces will be replaced with magnets!

Tags: frameworks, object-oriented, design patterns

In The Every Project Framework - Part 1, I spoke of partitioning, and abstracting structure and infrastructure. Now Let's talk about how we do that.

Over the last decade, the most prolific and available Architectural Pattern introduced and adopted by business developers is the Layers pattern. Call it by another name, but the concept is around everywhere. Most enterprise systems have open or closed Layers. They have many names, but Data Access Layer, Business Layer and so on, are often used. This a good thing towards raising the level of abstraction, increasing the infrastructure and providing more structure. However, having layers, does not automatically mean your application is on a good footing.

Raising the bar

If you are very skeptical, read the 'Why' section below first.

What do you think of your objects? How do you think of them? Are they transportation, containers, db table wrappers or other? Majority of business applications I see, have objects as a 1 to 1 mapping to a database table and it effectively is a container for a row of data. Some then wrap it into a collection of these rows and you have a table. Is that really what you need? is that efficient and good practice? Does it raise the bar high enough?

The first thing to say is that wrapping your table into an object is not entirely bad, as it is a level of abstraction away from the table.
However, if its at the highest level of abstraction you go to, then you will still have miles of code that you need to place elsewhere. Code such as Context, Security, Permissions, work flow and so on. If you manage all of your Types as a 1 to 1 mapping to the database tables, are you not merely writing code against the database?

If its UI (form) accessing and using -> the DataType Person, then your level of abstraction to the data is almost zero. You have abstracted the concept of a database table and replaced it with a more crude version, which you are populating.

Then the relationships and structure between all these singular Types will slowly come together within your UI, behind your button, in some method of some obscure class. Instead, the singular classes should be a little more structured and the bar should be raised higher, providing your UI with more closer, ready and easier to use objects.

To repeat in more a programmatic way, consider a table named Person.

If you have your UI --> Types --> Table

effectively you have abstracted a Row and Column concept away from the UI and replaced it with a PersonType and a PersonTypeCollection.
That means the UI, must understand how to deal with these Types.

To raise the bar, you would have more abstractions between UI and database
perhaps more like so

UI --> PersonCompositeType --> transaction(PersonDataType1/PersonDataType2) --> Table1/Table2

So PersonCompositeType is at much high level.

Please note:I am not saying that your architecture must look exactly like this, what I am suggesting is that more levels of abstraction can be achieved between the UI and your 1 to 1 mapped Type, that is so commonly found.

Why?

Have you ever had the following in your last or current project?

The UI is a lot more work than writing the "engine" or "business layers"!
Well of course it is, because the level of abstraction for the business layer is so low.

Your project starts quickly, progress seems to be made at speed, and then it slows right, right down....
It would, because, laying out database tables, getting your SQL and business objects in a 1 to 1 mapping is easy. Tying these low level abstraction together into a working application is harder.

Are you using a workflow engine? Are you using a business rules engine? Do you have isolated, stateless services? Do you have wrappers, commands, actions?
If not, then all the workflow, business rules, services are tucked away, most likely in your user interface. If you don't think you need these things, your large projects are most likely failing, running late and/or getting harder and harder to maintain.

Closing thoughts

If you think in "the ways of frameworks". Not as a framework that will be released to the world. Not as a time consuming lets focus on the framework, but rather build it, partition it and expand it within the project, your application will benefit from having more structure and more infrastructure.

Even having one of those is vastly beneficial. That is why a company with their own libraries (infrastructure), can get an application up quicker, even if its not a framework. One or both infrastructure and structure is vital for reuse and time to market. Yet, there is very little training going on at university, or courses in this area.

We should be training developers from their earliest years in software to think about reuse, to understand patterns, and putting rudimentary frameworks together.

Don't let the fact, that there are no perfect frameworks out there, lure you into thinking frameworks are bad. They are just diamonds in the rough. Most importantly, the "good" aspects of frameworks can be used within your application to high rewards. But how do you do it? -- stay tuned...

Tags: frameworks, design patterns, methodology

In The Every Project Framework - Introduction, I spoke of structure and infrastructure, lets now move a little deeper.
More...

Tags: frameworks, architecture, design, design patterns, methodology

When creating a large project, it is sometimes extremely hard to find names for certain things. So I have a small list. I mix and match ActivityItem, PropertyItem, ElementFactory and so on. Helps with those generic classes you cant find names for!
you probably already using most of them, if not all ..... (got more for me?)
More...

Tags: naming conventions, class names

Do you think of a Framework as a large 'hole, to be avoided'? Are they too complicated to develop within your project, for everyday development?
I take the view, that a Framework can very easily be part of every project you build, and with great benefit. You just have to understand how.

A Framework has two very important characteristics to give to Applications. A Framework provides structure and infrastructure.

More...

Tags: frameworks

To conclude the previous two posts on using composition for refactoring complex classes

Refactoring complex classes using Composition Part 1
and Refactoring complex classes using Composition Part 2

Why should complex classes be refactored? To make code smaller and more manageable. To separate code that changes at different rates, and which are not concerned with the same things.

Composition vs Inheritance? Composition = "has a" relationship, Inheritance "is a" relationship. Inheritance quickly makes you feel like you create Object-Oriented code, but its one of those devices that should be used for a real reason, not just off the cuff.

Reading
- Some background from C2 Wiki - Composition Instead Of Inheritance
- A good principle from Evolve aggregations from inheritance heirarchies - Brian Foote and William F. Opdyke
- Look at Adaptor, Facade, Proxy from Design Patterns (GoF) and also the Stategy, which is mentioned here by Erich Gamma A Conversation with Erich Gamma, Part III
- Refactoring Catalog - Martin Fowler
- Refactoring posts - Martin Fowler

Tags: code, refactoring, oo, composition, inheritance

FeelGoodFactor

I follow the FeelGoodFactor principle. Requirements at first glance can be cloudy and messy. It can ambiguous and abstract, or it could just be plain daunting. However, you need to list what you can, and the attempt 'solves'. By solves, I mean a logical route to a solve, a prototypical solution to that problem, or at least common consensus by a few good men (cough). You need to get most of the areas in your head sorted, and then commit a bit of that solution in your head to paper and a review by your peers.

More...

Tags: onix, xml, standards, uml, design, methods

No matter what software development methodology you adopt, you will always be faced with 'design' that is between good and bad, between necessary and unnecessary, between complicated and over-complicated. Design, even if it is technically good, can have disastrous effects on the project, if implemented incorrectly, or creates discord within a team, misunderstanding. In fact there are so many reasons, it would be better just to tell you what good design is. That's if I could, but I can't!.
However, I can say that Design is one of the most important factors for a project, it influences time lines more than anything else. Underdesigning, or overdesigning, neglecting to think ahead far enough, not including certain implicit requirements can all add days and weeks to a project.

Most of the time, its in your hands

A project requires thought and understanding. It takes a wide range of thinking outside of the box, thinking realistically, but yet being extremely open to ways of improvement. Here are three activities that will definitely aid your methodologies, skydiving and chess and music.

More...

Tags: design, methodology, simple software design method

Oh what joy. Fons Sonnemans and Loek van den Ouweland have created a repository for ExtensionMethods. Go on, you know you want to. The site ExtensionMethod, allows you to submit your own creations to the community.

Now I had this idea, just around 10 minutes before I found the site, so they beat me fair and square. (By a mile). So therefore here is my top three ideas for the site, which I had, and hope they think about.

1. Grade it
Allow us to vote for it. However more than that, flag it with Compiled, Tested. Little icons that the site show next to each method.

2. Open Source the ExtensionMethod
Allow the community to edit the code, which will improve it over time. If I use it, and it fails because of something small, allow me to edit it, and solve the problem for everyone. Add original author, and contributor names to the list. Perhaps allow an 'Editor' per Type, to look after it and make sure its tested and complete.

2. Give us an Assembly
Run a build, once a month, compile all the snippets, which could be done automatically, if you get the correct data from the submitted snippet.
As part of the grading, is whether your automated compilation worked, when including the snippet. (snippet compiler like, compile on the fly and validate the method).

Now we can all download an Assembly for all these community driven ExtensionMethods. Updated: I found this nice, yet strangely odd set of ExtensionMethods for boolean.

Tags: extensionmethods, c#, vb.net

We all know that the learning curve for Frameworks are quite high. We all know that Frameworks demand commitment, and learning time. We know this because we struggle with it everyday, whether its Java or .NET, Swing, or MFC.

1991-1993, Ralph Johnson and others wrote about Recipes and Cookbooks. There have been papers on documenting frameworks for more than 15 years. MSDN has some of the flavours but none of it is actually polished, nor tailored to the audience and the way in which people seek information.


My D4 Software Frameworks Pattern Language points you to some Patterns for documenting Frameworks:

WritingReference
You must provide a reference of interfaces.
WritingRecipe
You need to provide examples of isolated features of the framework that a pure reference cannot show.
WritingCookbook
You need to combine a large amount of recipes.
SelfDescribing
Using tools and generators, you can generate documentation.


All of them are self explanatory, except let me add, amazing that blogs seem to be the number 1 source for this kind of information, as well as google tends to find things on MSDN better than MSDN finds on their own material?.

The Solution to the MSDN Dilemna

The last one (SelfDescribing) is where I am particularly keen. Not GeneratingReference but SelfDescribing Imagine if a method on a class called MethodA() had been marked with an attribute called TemplateMethod()

Well a Tool, would be able to highlight it for you. If you had a tree of all Types, TemplateMethods and Hooks, you would now better understand the way in which the types where constructed. You would now know that MethodA() called Method(B) then MethodC(). The internals of MethodA() ois not known, shown or cared for. But from a documentation point of view it is crucual for certain designs.

It is this, that is missing from MSDN, because it is missing from all frameworks. Documentation needs to be better, but cannot, until the compiled code, can be examined in a much more thorough way. Developers of Frameworks, must declare their intentions of methods, class and patterns by attributing metadata onto it.

So the solution, is to mark the .NET Framework Types with documenting metadata. Allow all Framework developers to utilize this metadata descriptions for their frameworks, and provide a tool to inspect it.

Tags: msdn, documentation, frameworks

Effectively, here is an Index to the pattern language in draft.

A Pattern Language for Designing, Developing, Documenting and Deploying Object-Oriented Software Frameworks

More...

Tags: frameworks, design patterns, coalescent patterns

Two comments came through to me regarding AgileDesign. It was pointed out that Agile is a loaded term, and perhaps I should look to rename it. Another aspect mentioned to me in an email, was that Extensible and Agile are probably the same or too similar to be different principles. The thing though, is that my AgileDesign, is exactly "Agile" Design, and although Extensible and Agile are both concerned with change, there is a very important difference between them.
More...

Tags: frameworks, design patterns, coalescent patterns

The majority of Software is quite multicellular. This sounds quite good, but in fact, its not even a small insect yet. or one could argue they are at the bug stage. Software tends to be rude, uncultivated, and unevolved, mainly due to LackOfEvolution.

One of the significant aspects of this, is that focus is granted to the development of the initial project, and then a handful of people (or if you are unlucky, just you), who are burdened with supporting it afterwards. This basically means "bug fixes until death" and lots of phone calls and emails later, you lose the lack of thought and action, but the software does not evolve. Software suffers from LackOfEvolution

Why do I say this
I say this because the vast majority of software only undergoes one full life-cycle. It may then get a smaller cycle of a patch or update, but most do not go to version 2 with the same code base. Version 2 tends to have very little of the original team members, and the code may very likely have completely rewritten areas. Version 3 even less of anything original. It may even have a new technology or language that it uses. Developers also enjoy writing their own code, rather than using other code, so this makes it easier to rewrite.

solution?
The problem is that the software does not get time to age, mature and be cultivated.
We need that extra time. An extra cultivation iteration is needed in all software teams, on any project. Create a planned version 1.1. Get your full team to conduct a special maturing cycle, where they add a few features, refactor code, shuffle things around. Plan it properly just as you would the first life-cycle.

LackOfEvolution for Teams

Software Teams can suffer from LackOfEvolution also. Developers can sometimes get caught in a project and not learn new things while they are busy on a project. You get to the end of a two year development and realize a few things have passed you by.

solution?
It is vital to stimulate debate about code, to have a trainer in for a day, to get show and tell sessions by members of the team, and other useful activities to counter act the stagnant waters. If you don't do SCRUM, have a SCRUM week, where you follow SCRUM for the week and evaluate it. Have a CompetencyFramework fro all developers with a plan on their evolution within a project and technology. We all need evolution, of character, skills and understanding, it is how we get better.

Tags: methodology, design, design patterns

Traditionally, you read about the following two types.

Vertical Frameworks
or an Application Framework that covers all the elements top to bottom. It may be narrow, or relatively wide. However, it is most likely to be specific to a type of Application and not concerned with cross application reuse. For example: Employee Benefits, Batch Manufacture, Ledger and things of that nature. It would contain its own logging, errorhandling, data access, auditing. It would allow extensibility, configuration, but from a vertical perspective.

Horizontal Frameworks
or Infrastructure Framework is concerned with the wider services, and does not dictate the higher layers of an Application. So it would contain a wider range of services, but offer less vertical specializations.

More...

Tags: frameworks, horizontal, vertical, design patterns

Not spliff, split.

ReuseSplit is simple.
Getting true reuse takes time, and effort, and thought, but with ReuseSplit, you can achieve a good percentage. It also provides a focus for reuse, where it can grow.

Two (Inter)Faces "if you are as two faced as momma always says, why do you always wear that ugly one?" - anon

Generalization and Specialization. Split your code out into these two (inter)faces. The Generalization should be contained within a separate project. The Specialization within your current project.

Its not revolutionary, its simple. However, the majority of code in the business looks like Specialization only. Then perhaps what is common, then perhaps something reusable. However, by ReuseSplit, you are immediately doing two very important things. You are splitting what changes from what does not, and you are developing with reuse in mind, which creates separate code for reuse later, which means you are developing malleability into your solution as well.

Generalized

When we say, lets create a "Generic" something, we mean something that is versatile, more or less common, more or less reusable, more or less specialized.

By generalizing, we convert, "The quick brown fox jumps over the lazy dog", to "the (adj) animal jumps over the (adj) animal".

Now we know we need two instances of an Animal class, and some descriptive attributes that can be applied to the Animal.
This does not mean inheritance, it could be implemented in any sort of way, its the separation of Animal and Fox that is key.

Specialization

If you need a specific Fox, then build one, using the Animal, whether by composition or inheritance. The Specialization then feeds the Generalization. If it is common move it down.

By using this technique, thinking about ReuseSplit with everything I do, I like to think that I make an extra 10% of reuse on code, without thinking. Like driving a car, I don't think about it as I am doing it, however, reuse is usually higher, when I hit a project.

Tags: design, frameworks, design pattern, reuse