OO

Developer Book Syndrome

Ben Kloosterman — Sun, 01 Nov 2009 13:33:07 GMT

A colleague of mine once stated that creativity is rare in technical people I had my doubts at the time as I’m fairly creative and often build unorthodox solutions tailor made to the problem but the longer I’m in the industry the more I agree.

The biggest symptom of this is something I called book syndrome. This is where famous author xyz ( eg Lowly , Fowler etc etc ) writes a strategy in a book and people use it in completely in inappropriate circumstances. When challenged on the solution they use the authority of the author to emphasize they are doing the right thing. While this technique may provide some job protection it is questionable that the famous author intended to apply it where it was applied ( eg Juval Lowly SOA 1 service per class ) and in many cases like Fowler there are many methods yet a single patterns is repeated ad nauseum without any concern for the special cases for each project..

And it is not just books, Universities have a lot to answer for drumming in OO yet for a lot of small to medium projects scripts and RAD provide better and more consistent results ( OO /RAD is Software theory relevant) . The fact is the bedrock of nearly all programming theory is based on 90% of the cost of an application being maintenance while true in the 50-80s this is clearly not true in the huge amount of small applications and scripts that never enter software studies ; in fact most of these programs never change over the life time of the program ( and are completely rewritten in a new technology after 10-15 years) is completely at odds with most of software development theory. I’m not against OO but I am against using OO in many inappropriate situations ( eg blindly following book – book syndrome) – even in an OO house RAD development will be faster , cheaper and deliver more reliable project deliveries.

The whole concept of an OO development house , an SOA house or a RAD house seems very wrong . Each has their pros and cons for each project and any competent team should be familiar with all techniques and use them where appropriate.

Every project needs to be taken on its own merits and facts like these are FAR more important whether OO is better than RAD or SOA.
- Amount of change /maintenance over the life of the project
- Fixed price contract
- Team skills (Architecting for the team)
- Breaking down the work ( eg SOA service layer and RAD front ends)

SOA 1 class per service Juval Lowy framework

Ben Kloosterman — Sun, 01 Nov 2009 13:12:25 GMT

I posted this a year ago.... I'm really against this make each class a separate service concept. It reminds me of the Microkernel and especially workplace OS but worse. The idea of microkernels was each service ( like memory) was an easily managed entity with carefully defined inputs and outputs which could be consumed.) Workplace OS took this to limit and performance was so poor that no amount of optimization would help. So they had no choice but to scrap the project ( were talking $2B 10 years ago) the bad thing is once such a design is made and implemented just like workplace OS it is very difficult and expensive to fix. Classes by nature frequently communicate with other classes ,serializing everything makes this far to slow. Think about big orders with 10,000 line items each line item could be a separate service call to add up some total and what do you gain ? I consider service to service communication and some sort of nearness analysis a vital part of SOA and grouping related classes into services will help significantly by - Increasing performance - Allow for better maintenance and less change as related changes will deploy together . - Allow for better OO/maintenance and Agile techniques within each service. ( though less outside) - Allows better integration and use of different services such as Java , CRM/ERP services etc. - Encourages chunkier cross service calls and better attention paid to the service interface ( for easier use, compatibility/maintenance and performance) - Discourages the service as a DB store proc wrapper. - Avoids having to put performance hacks in the wrong place to try to avoid cross class calls. This does not mean services should be 20 classes 3 is a good line but 1 to 9 is ok in a number of cases depending on class relationships. Basically if 2 classes communicate all the time they should be in the same service. I can see in 5-15 years hosted environments/frameworks hosting classes which can be moved to machines or be in proc though its far too early for this and you NEED the ability for classes to communicate via normal inproc ( without serialization) . I not you mention this for the future but telling people to use each class as a service now without some more comments on the hazzards ( especially when they don't have a lot of experience in SOA) will lead to a lot of frustration for some .

POS or SOA Lite TODO

Ben Kloosterman — Mon, 09 Feb 2009 05:34:40 GMT

I think Service Orientation has gone the way of J2EE/ EJB and needs to be pulled back like was done with POJO.

I propose POS Plain old Services or POSA for Plain old services architecture.

Rules.
1) There is only one rule and that is KISS.

Is there a roll for OO in SOA

Ben Kloosterman — Thu, 05 Feb 2009 03:58:38 GMT

From Richard Turners blog

SO and OO are complementary technologies:

SO is how one thinks about building systems as a whole:

A System is a set of deployed services cooperating in a given task
- Systems are built to change
- Systems adapt to the introduction of new services after deployment.
A service is a program you interact with via message exchanges.
- Services are built to last
- Availability and stability are critical and the responsibility of the Service Owner.
- Services are fractals – one service can contain other services, which can contain other services, …

OO is important WITHIN the service boundary

OO technologies and approaches are used to build a service physically

OO technologies store and retrieve data to/from internal data stores, perform calculations or business functionality, etc.

This is “business as usual” for most developers

OO is good at reducing, managing and modeling complexity however it is quite likely that many services will result in anemic domain model in which case OO looses most of its benefits. For these smaller services they will look Procedural regardless of the technique used.

Is SOA a Belief system and what does that mean for Team dynamics

Ben Kloosterman — Thu, 05 Feb 2009 03:37:11 GMT

Best SOA posts on the net ( and the comments)

http://blogs.msdn.com/richardt/archive/2005/12/13/503358.aspx

This is what I believe SO is ... it truly is a belief system and a way of thinking. It is not a prescriptive architectural process or methodology. It's not a template that you can apply that results in a service oriented system. It's where art meets science. It's where aesthetics meets engineering. It's the thing adds a human touch to the things we create. It's inside of me and it's inside of you....

james governor said:

i am with anil. a call for an epiphany is kind of hard. you ever read any wittgenstein?

"My propositions are elucidatory in this way: he who understands me finally recognizes them as senseless, when he has climbed out through them, on them, over them. (He must so to speak throw away the ladder, after he has climbed up on it.)"

this kind of intellectual bootstrapping is an issue. also - how many people ever "got" objects. you are making an argument for a priesthood, not a revolution in software productivity.

i see too much of this from the vast IQs at Redmond. you guys need to understand not everyone is as smart as you are, and not everyone writes the kind of beautiful code you aspire too. You build tools for the masses, not for the geniuses eh.

Ben Kloosterman said:

I do agree you need to make the leap , if you have not build distributed systems before ( remoting , Corba/ RMI or web service) you will not know why it is needed. Too many variables to explain which means you will never convince people.

A bit Like TDD in the OO space ( and OO at first) people just have to try it .

I wrote this in 2004 ( 5 years ago now !) and i still believe this, jumping to SOA is a leap and unfortunately some people who have not done distributed apps before have to learn through pain . As James rightly points out though many people nevery made the jump to OO which ALSO requires a leap of faith. With OO the industry has different ideas how high to leap .

That being said i think the best thing is to design for the skills of the team ! A small app is probably best represented by 2 Tier database. A large distr. app or SOA environment is going to have people with all varieties of skills. People with good OO skills can create complicated clients , framework , services etc , people with distributed app experiences can write the contracts , framework and services , VB Procedural programmers can write clients that consume the services. In all cases because SOA services have a SIMPLE interface ( if designed well) and treat the services information as data all people can use it including different languages. In that sense organisations do not need to standardise as much as earlier . Most importantly people dont need to make the LEAP to SOA they can keep doing what they are comfortable with and willing to learn. With Distributed Objects you needed a lot of people to have great OO and distributed app skills a pretty big ask for most organisations. This is a big improvement.

DTO pattern

Ben Kloosterman — Thu, 05 Feb 2009 02:17:21 GMT

http://msdn.microsoft.com/en-us/library/ms978717.aspx
http://martinfowler.com/eaaCatalog/dataTransferObject.html

I still think Martin Fowlers description is best

An object that carries data between processes in order to reduce the number of method calls.

While DTOs were designed for the above they provide key benefits to distributed systems

1.Performance

Typically Objects in OO have quite a chatty interface , this is good for design purposes as these communication mirror the relationships between the objects however the performance implications for distributed systems are significant and worse the worry about performance last mentality in software development makes a significant issue as these issues are VERY expensive to fix as the design from the start is flawed. A simple example is Order and OrderItem while an order with a thousand line items may iterated the Items in memory in a microsecond ( say to addup the total) , in a distributed system with OrderItems in a different service this could take seconds (or more) . Much better to send all the Orders and OrderItems in one operation and then do the work required. While this is an obvious example most real life systems will have MANY issues with such chattiness which are not so easy to deal with.

2.Remove Leaky abstraction from your domain model and hence improve maintenance

Another benefit of DTO's is they preserve your business logic from contamination by the needs of the outside world and hence make the system more easy to maintain. The performance issue mentioned above is one. Another common one is since you maybe communicating with other systems a change may be required in your system which if you are not using DTOs will propogate through the whole system ( eg support for DateTime? instead of Datetime for a Java client) . Its best to have a DTO be responsible for serializing the class ( and deal with the limitations of the transport eg XML). Is your Order class really responsible for its wire representation so why make it so ? Windows Communication Foundation doesn't support generics why limit your domain model by not allowing them , this is a perfect example of the leak abstraction you get with distributed systems - All such frameworks leak and hence you violate the basic OO rules of responsibility. Clearly your domain objects should NOT be responsible for working with the communications framework (whether EJB , Windows Communication Foundation etc) or underlying data ( eg XML)
so why make it so? Also note communication errors can occur in the middle of you business logic code ? Is it the responsibility for this code ? Preserving your domain model as designed will make it easier to maintain your code. Leave the DTOs/Fascade to handle the real world.

3. Appropriateness of Domains

All systems have different ideas of what a "Person" or "Car" is , while a single application domain does not have this issue as much the more clients and services you get the more it becomes an issue. This is especially true of SOA systems. By treating the information from the server as Data ( and Procedures) each application can have a unique view of what a "Person" and "Car" is and hence map its solution closer to its real world model rather than trying to force the real world model for a new part of the system onto the current application. This is not really a DTO benefit but DTO's allow the more completes seperation of logic eg the sever converts the DTO to its logic and the client does likewise.

For example with a client UI by exposing Domain objects to View layer, Views become aware of structure of domain objects, which lets the view make some assumptions about how related objects are available. For example if a domain object "Person" was returned to a view to which it is "bound" and on some other view, "Address" of Person is to be bound, there would be a tendency for Application layer to use a semantic like person.getAddresse() which would fail since at that point Address domain object might have not been loaded at point. In essence ( or require more chatty communication via lazy loading) , with domain objects becoming available to View layers, views can always make assumptions about how data is made available. Also the reverse when domain objects are bound to views (more so in Thick clients), there will always be a tendency for View centric logic to creep inside these objects making them logically corrupt. (note the similarity with the above messaging framework /wire transfer logic creeping in)

Easier to Maintain , better performance so why are DTO''s rarely used in a lot of systems ?

People seem obssessed with using tools and most tools ( and a lot of design methodologies) are focused in an idealized world and like to use the same object throughout the distributed system. However real world practicalities then quickly reduce the quality of the domain model code. Such as focusing with serialization issues etc .

There are issues with use of DTO's also since use of DTO creates additional work in terms of creation of Assemblers (DTO to Domain objects and reverse), Proliferation of analogous objects like Patient domain object, Patient DTO ,PatientDTOConverter ,PatientView ( if not directly bound) . However note each of these Patient domains has a clear roll and the objects themselves are easy to create.

I think DTOs should be used in ALL services unless you can write the service in a few days. Small anemic domains do not require them.

Why do larger projects fail more often?

Ben Kloosterman — Thu, 15 Jan 2009 14:37:38 GMT

Since larger projects have more opportunity to learn ans share code why do they fail more ?

However the report does not show all good news. Time overruns have significantly increased to 82% from a low of 63% in the year 2000. In addition, this year's research shows only 52% of required features and functions make it to the released product. This compares with 67% in the year 2000.

OO with services

Ben Kloosterman — Wed, 14 Jan 2009 15:33:15 GMT

Are OO code and SOA diametrically opposed ? In a lot of ways this is true services tend to produce very anemic object models however this merely reduces reuse which is a myth in OO for the majority anyway .

However services have a unique but familiar problem . The contract of the service is critical it needs to be designed for

- The ease of use of the client

- For performance ( ie chunky calls , many small calls can bring many services down to its needs)

- To be upgradeable and allow backward compatibility.

- Compatible with an XML schema ( eg generics and interfaces create problems)

- Best to be compatible with WS standards and non Windows Communication Foundation clients ( eg nullable datetime , no char , long etc )

- Only sub object and collections needed for this call need to be propagated which is not all the objects and collections a object may contain. eg Order GetOrder(..) may contain OrderItems which contain Products but no more information about the product such as supplier etc . This is best described as truncated trees.

( see how to write a good contract)

This is dramatically different from an OO structure where ease of use is not high on the list else we would all be using statics , however its very similar to a relational database and its structure.

Does this mean services are similar to databases ( eg Procedural Programming) ? From the outside yes and smaller services probably should remain Procedural and non OO . (A good example is in the LINQ and services article)

However larger services should retain a significant OO core with a focus on code quality , testability and maintainability however this requires a reverse ORM which maps from the messages to the internal logic. Microsofts P&P Web service factory includes converterts exactly for this purposes and its a good pattern to follow.

Even in small services when mapping from a DB to messages there is a case for such a conversion layer ( and DTOs) . Take the case of LINQ for sql if you add a member to a DB table for some new functionality meant to be visible to a select group do you want every client to now have this information in the data sent down ? If custom message contracts were used only the new operation and contract used by the select group would get the new information however all the logic would be common ( just the privileged data would not be copied to contract) . If custom message contracts are not used the team would be forced to create a new schema copy of the data for the same table which would be identical except for the one member as can be seen over time this would reduce maintainability of the service .

How to write a good service contracts

Ben Kloosterman — Wed, 14 Jan 2009 15:10:47 GMT

... not hand craft wsdl

Custom messages reduce churn and change in the contract

Lets say you have this datacontract

[DataContract]

public class WorkEntry

{

[DataMember]

public DateTime StartTime;

[DataMember]

public TimeSpan Duration;

[DataMember]

public string User;

[DataMember]

public string CostCentre;

[DataMember]

string Comments;

}

What can go wrong here ? Using public fields is good , its tight and if you need to do custom things you can refactor it easily. I think there is nothing really wrong here however if this is a business object also i would be concerned.

The big gotcha maybe DateTime , lets say you have some other systems in your company that use Java . Now Java systems use a nullable DateTime and can send null ( and DateTime.Min can become null if emit default values is false) causing all sorts of issues . Management decides YOU must change however you have used this as a business object through your app . You can change the DateTime to DateTime? However there are a large amount of implication to your application in now having to deal with possible null values - including the SQL server and DB and hence what is a trivial change requires pretty a lot of work and risk and hence testing ( note TDD or unit testing here do not help and make it worse as the unit tests also have to change) .

The problem here comes from using your DTO ( data transfer object eg message /DataContract) as your business object. I think this should be avoided in all cases where the service is non trivial. In Trivial services its easy enough to write a new service or make the changes and hence using the business object as the message is ok.

Avoid .NET specifics especially

non int integer types
char
generics ( not that it works)
serializing interfaces
inheritance

Ultimately messages are serialized as XML and forcing a object model onto it will always result in difficulties and leaky abstractions for the domain. The solution is simple DONT let WCF and your communications contaminate your object models use the DTO(Data Transfer) pattern.

see DTO pattern.

Post by Frans Bouma

Ben Kloosterman — Tue, 13 Jan 2009 13:04:08 GMT

Loved this post so had to emphasize and post it.

"That's not the case. A framework user doesn't give a **** about how many different patterns the framework is using and how great and awesome it's internally and how it will ultimately evolve in the bringer of world peace. A framework user is interested in whether the framework takes care of things the framework user can't afford to spend time on. After all, the framework user can't afford to spend time paid by the customer on plumbing, on writing infrastructure code. The framework user is paid to write code directly related to the problem at hand: the application for the customer. No customer should accept that the team hired for writing the line-of-business application has spend time on writing a report-control or for example a grid control. So why should a customer accept to pay for time spend on other plumbing code? Just because the customer doesn't know any better? If so, isn't that erm... taking advantage of the inability of the customer to judge what the 'software guys' did was correct?

Yes, it's that extreme. The software industry should grow up and realize that it shouldn't be acceptable anymore to write frameworks and framework code, plumbing code etc. paid by the customer, just because the customer doesn't know any better. And we, the software developers, should grow up and accept that the job many of us have isn't to write plumbing code and infrastructure code, but to write code using the plumbing available. If the plumbing at the place where you work is broken, it's very likely that someone will call a plumber to fix it. So why accept that if the plumbing used for a project is broken, one has to fix it themselves? With all the bugs, loss of time, focus and ultimately: money, as a result? "

I dont think its extreme at all , the same attittude in the industry is pervasive ( See where has the productivity gone) . The industry routinely delivers software that is over engineered for the job and the additional code and complexity instead of reducing maintenance actually makes support and maintenance more costly. This also applies to implementing SOA and EDA architectures for organizations which are too small to see the benefit.