1/2 Things to Make You a Better Object Oriented Programmer

Last year, OreDev organized a developer Conference in Malmö Sweden. The theme of the conference was called “get real”, it was about how to stay in balance, between today’s realities and tomorrow’s possibilities while the universe is in constant motion.

One of the more interesting session for me was a session by Grey Young called “19 1/2 Things to Make You a Better Object Oriented Programmer”. In this talk he discusses several things to improve your object-oriented programming skills and more importantly give you explanations on the thought processes behind the ideas.

Greg Young for people who do not know him is an independent consultant who lives in two suitcases (literally). When not travelling around working for clients throughout the world you can often find him on the domain driven design list, blogging at codebetter.com, or floating upside down in a kayak through rapids.

During the talks he mentions the followings things which will make you a better regarding object-oriented programmer.

1. Class != Object

Explicitly making the distinction between classes and objects is important. A class is nothing more than a template where objects are instances of these templates. These instances do not necessarily look like the class. In modern object-oriented programming books,  not much attention is given about the difference between classes and objects.

2. Method Call = Message

Calling a method on an object is the same as sending a message to an object. Many of the earlier object programming books use sending a message and calling a method interchangeable. When you look at it as sending a message interesting possibilities are possible. For example filtering the messages when they go through the pipeline. This for example would enable setting a trap to catch specific messages when you are testing an object. This will remove the need for mock frameworks.

3. Objects are not “data”

Objects are data and behavior put together. Many domain models consists only of objects with getters and setters without any behavior in any of them. On top of these objects sit a layer of services that interact with these objects. This describes procedural code and the result is called an anemonic domain model. In his talk Greg discusses if this is a pattern or an anti-pattern. The conclusion was that if you intent to create an object oriented domain model and the result is an anemonic domain model it is an anti-pattern. If on the other end you choose for this anemonic domain model because the development team has little experience with object-oriented programming it is a pattern.

4. Is a?

An “Is a” relationship between two classes is the strongest possible coupling you can create in C#. When you create an inheritance tree with multiple levels, maintenance becomes a nightmare especially if you introduce a new relationship. For example, having an inheritance tree with in it a plant and an animal and adding a virus to it which is both a plant and an animal. A better alternative for a “Is a“ relationship is an interface implementation. With an interface you only couple the behavior instead of the data and the behavior.

5. Dependencies should point in

The difference between procedural code and object-oriented code is that with procedural code dependencies points outwards and with object-oriented code the dependencies point in. For example the following procedural code needs a reference to System.Console.

1	void WriteMessage(string message)

2

{

3	Console.WriteLine(message);

4

}

If instead the constructor of a class would receive an ITextWriter interface which has a WriteMessage method like below there would not be a dependency to System.Console. The user of the MessageWriter class should create an implementation of the ITextWriter interface and therefore depends of the ITextwriter interface hence pointing the dependency in.

01	public class MessageWriter

02

{

03	private readonly ITextWriter textWriter;

04

05	public MessageWriter(ITextWriter textWriter)

06

{

07	this.textWriter = textWriter;

08

}

09

10	void WriteMessage(string message)

11

{

12	Console.WriteLine(message);

13

}

14

}

15

16	internal interface ITextWriter

17

{

18	void WriteMessage(string message);

19

}

According to Greg this is the core concept of OO programming. This inversion of dependencies could also be done with messages for example use events to invert the dependencies. In system integration this is one of the reasons for choosing a push model instead of a pull model. You invert the dependencies between the systems.

6. Constructors are special

Constructors are special methods that create our objects. The dependencies of an object that are set through the constructor should always be read-only. See the example below in which the textReader and textWriter dependencies of the MessageWriter class are both read-only and therefore cannot be changed once the instance of the class is created.

01	public class MessageWriter

02

{

03	private readonly ITextReader textReader;

04	private readonly ITextWriter textWriter;

05

06	public MessageWriter(ITextReader textReader, ITextWriter textWriter)

07

{

08	this.textReader = textReader;

09	this.textWriter = textWriter;

10

}

11

12

.....

If you need to change the dependency of an object during the lifetime of that object you probably need a new instance of that object with a different dependency. If you really need to change the dependency during the life time of an object you would be better off injecting that dependency as a parameter of a method that needs that dependency. This according to Greg will solve many of the complexities during the development. See below for an example.

1	void WriteMessage(ITextWriter textWriter, string message)

2

{

3	textWriter.WriteLine(message);

4

}

7. Single Responsibility

The Single Responsibility Principle is one of the SOLID principles and describes that there should be a single reason for a class to change. Greg discusses what exactly is a single reason or that one thing? If you go to far with single responsibility you end up with procedural code. All classes would contain only a single method. Therefore he describes that single responsibility should be a trade-off with cohesion. Cohesion is the amount that fields or the data of an object is used by the members of an object. For example a class that has perfect cohesion uses all its fields  in all the methods.

8. SOLID are heuristics to Ca, Ce and cohesion

The SOLID design principles are simply heuristics to afferent coupling (Ca),efferent coupling (Ce) and cohesion. The SOLID design principles such as SRP (Single Responsibility Principle) are simple teaching tools that are easier to understand than the underlying principles. If you want to become a better programmer you should strive to understand these underlying principles and concepts as they are more important. For example afferent couple describes the number of types from an external assembly that are using the types inside your assembly. Efferent coupling describes how many type you are using from an external assembly.

Stability is calculated by determining on how many concrete types you depend against the dependencies on abstract types. Depending on abstract types is better and increases stability.

The table below shows several tools that can measure Ca, Ce, Cohesion and stability of your assembly. The advise is to use these tool to learn about the underlying principles and concepts of the SOLID design principles such as Ca, Ce, cohesion and stability.

Tool	Platform	Open Source
NDepend	Microsoft .Net	No
XDepend	Java	No
Sonar	Java	Yes
Sonar C# plugin	Microsoft .Net	Yes
Lattix	Microsoft .Net / Java / C++	No

9. LisKov is Special

The Liskov substitution principle is one of the SOLID design principles. Liskov is special as this is one of the most important concepts that you need to master. Liskov is important because the human brain is only capable of handling so many things at once. For example it is impossible to get an understanding of a system in which 50 or more objects interact with each other. Liskov enables you to break apart your object graph. You define separate subsystem that coupled using interface. Because the systems that are coupled with an interface are interchangeable they become better to understand.

10. MVC is not a UI pattern

Although controversial, MVC is not a UI pattern, it is an architectural pattern that has been proven to be useful in a number of situations, including with a user interface.

11. Value objects are important

Value objects are important because they make our code clearer and more easily to understand. For example Value objects such as money and a time span make code easier to read. Another thing that is important is that objects should always have a valid state. When objects always have a valid state there is no need to check all over in your code for the validity of your object. This will reduce the complexity of the source code.

12. DRY our psychology pattern

Most programmers know DRY or Don’t Repeat Yourself. This principle states that you should always strive to remove all duplication of code. Greg discusses that DRY has a trade-off with coupling. Say two classes A and B both have more or less the same method. By extracting this method in a separate class C and using this from both classes you create a coupling between classes A and B. This coupling did not exists with the duplication of the code. By using DRY we have increased the complexity of our code.

13. Model “useful abstractions” of the reality

With this Greg tends to warn about trying to model the world in objects. Many developers are modeling objects because they exists in the real world not because the software needs them. Only model object that are useful for your software.

14. Testing builds better objects, as does contracts

Testing or TDD forces us to build better objects. For example, objects with a lot of getters and setters are hard to test. The asserts of a test should be based on the behavior of an object not on its state. If you want to read a good book on object-oriented programming, read this one from Bertrand Meijer. Also using the new Code Contracts library in version 4 of the Microsoft .Net framework will make you a better object-oriented programmer.

15. Commands and Queries

All commands have avoid return type but are allowed to change the state. Queries can have any return type but are not allowed to mutate state. By separating this concern the complexity of our applications will decrease.

16. Objects play roles

Look at objects as a set of things that each play a separate role and work together to carry out a certain task instead of a single object that performs all the functionality of a task.

17. Models the boundaries of transactions explicitly

You should explicitly model which objects of your domain model are part of which transactions. Define exactly where the boundaries of each transaction are.

18. Pattern languages are about communication

A pattern language is a tool for easier communication. One should not force yourself to use a certain pattern or any other. They offer value in communication.

19. Not all code is or should be OO, boundaries are often not

Not all the code should be OO, the boundaries of your domain model will often be programmed using procedural code. For example services will exchange data objects, objects that only holds data and no behavior.

19,5 Don’t take yourself too seriously

Well this one speaks for itself. We all make mistakes and through these mistakes we learn.

description of HTTP STATUS

1xx Informational

Request received, continuing process.[2]

This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. Since HTTP/1.0 did not define any 1xx status codes, servers must not send a 1xx response to an HTTP/1.0 client except under experimental conditions.

100 Continue
    This means that the server has received the request headers, and that the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). If the request body is large, sending it to a server when a request has already been rejected based upon inappropriate headers is inefficient. To have a server check if the request could be accepted based on the request's headers alone, a client must send Expect: 100-continue as a header in its initial request[2] and check if a 100 Continue status code is received in response before continuing (or receive 417 Expectation Failed and not continue).[2]
101 Switching Protocols
    This means the requester has asked the server to switch protocols and the server is acknowledging that it will do so.[2]
102 Processing (WebDAV) (RFC 2518)
    As a WebDAV request may contain many sub-requests involving file operations, it may take a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet.[3] This prevents the client from timing out and assuming the request was lost.
122 Request-URI too long
    This is a non-standard IE7-only code which means the URI is longer than a maximum of 2083 characters.[4][5] (See code 414.)

2xx Success

This class of status codes indicates the action requested by the client was received, understood, accepted and processed successfully.

200 OK
    Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request the response will contain an entity describing or containing the result of the action.[2]
201 Created
    The request has been fulfilled and resulted in a new resource being created.[2]
202 Accepted
    The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place.[2]
203 Non-Authoritative Information (since HTTP/1.1)
    The server successfully processed the request, but is returning information that may be from another source.[2]
204 No Content
    The server successfully processed the request, but is not returning any content.[2]
205 Reset Content
    The server successfully processed the request, but is not returning any content. Unlike a 204 response, this response requires that the requester reset the document view.[2]
206 Partial Content
    The server is delivering only part of the resource due to a range header sent by the client. The range header is used by tools like wget to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.[2]
207 Multi-Status (WebDAV) (RFC 4918)
    The message body that follows is an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.[6]
226 IM Used (RFC 3229)
    The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance. [7]

3xx Redirection

The client must take additional action to complete the request.[2]

This class of status code indicates that further action needs to be taken by the user agent in order to fulfil the request. The action required may be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A user agent should not automatically redirect a request more than five times, since such redirections usually indicate an infinite loop.

300 Multiple Choices
    Indicates multiple options for the resource that the client may follow. It, for instance, could be used to present different format options for video, list files with different extensions, or word sense disambiguation.[2]
301 Moved Permanently
    This and all future requests should be directed to the given URI.[2]
302 Found
    This is an example of industrial practice contradicting the standard.[2] HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was "Moved Temporarily"),[8] but popular browsers implemented 302 with the functionality of a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours.[9] However, the majority of Web applications and frameworks still[as of?] use the 302 status code as if it were the 303.[citation needed]
303 See Other (since HTTP/1.1)
    The response to the request can be found under another URI using a GET method. When received in response to a POST (or PUT/DELETE), it should be assumed that the server has received the data and the redirect should be issued with a separate GET message.[2]
304 Not Modified
    Indicates the resource has not been modified since last requested.[2] Typically, the HTTP client provides a header like the If-Modified-Since header to provide a time against which to compare. Using this saves bandwidth and reprocessing on both the server and client, as only the header data must be sent and received in comparison to the entirety of the page being re-processed by the server, then sent again using more bandwidth of the server and client.
305 Use Proxy (since HTTP/1.1)
    Many HTTP clients (such as Mozilla[10] and Internet Explorer) do not correctly handle responses with this status code, primarily for security reasons.[2]
306 Switch Proxy
    No longer used.[2]
307 Temporary Redirect (since HTTP/1.1)
    In this occasion, the request should be repeated with another URI, but future requests can still use the original URI.[2] In contrast to 303, the request method should not be changed when reissuing the original request. For instance, a POST request must be repeated using another POST request.

4xx Client Error

The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents should display any included entity to the user. These are typically the most common error codes encountered while online.

400 Bad Request
    The request cannot be fulfilled due to bad syntax.[2]
401 Unauthorized
    Similar to 403 Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided.[2] The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication.
402 Payment Required
    Reserved for future use.[2] The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, but that has not happened, and this code is not usually used. As an example of its use, however, Apple's MobileMe service generates a 402 error ("httpStatusCode:402" in the Mac OS X Console log) if the MobileMe account is delinquent.
403 Forbidden
    The request was a legal request, but the server is refusing to respond to it.[2] Unlike a 401 Unauthorized response, authenticating will make no difference.[2]
404 Not Found
    The requested resource could not be found but may be available again in the future.[2] Subsequent requests by the client are permissible.
405 Method Not Allowed
    A request was made of a resource using a request method not supported by that resource;[2] for example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource.
406 Not Acceptable
    The requested resource is only capable of generating content not acceptable according to the Accept headers sent in the request.[2]
407 Proxy Authentication Required[2]
408 Request Timeout
    The server timed out waiting for the request.[2] According to W3 HTTP specifications: "The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time."
409 Conflict
    Indicates that the request could not be processed because of conflict in the request, such as an edit conflict.[2]
410 Gone
    Indicates that the resource requested is no longer available and will not be available again.[2] This should be used when a resource has been intentionally removed and the resource should be purged. Upon receiving a 410 status code, the client should not request the resource again in the future. Clients such as search engines should remove the resource from their indices. Most use cases do not require clients and search engines to purge the resource, and a "404 Not Found" may be used instead.
411 Length Required
    The request did not specify the length of its content, which is required by the requested resource.[2]
412 Precondition Failed
    The server does not meet one of the preconditions that the requester put on the request.[2]
413 Request Entity Too Large
    The request is larger than the server is willing or able to process.[2]
414 Request-URI Too Long
    The URI provided was too long for the server to process.[2]
415 Unsupported Media Type
    The request entity has a media type which the server or resource does not support.[2] For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.
416 Requested Range Not Satisfiable
    The client has asked for a portion of the file, but the server cannot supply that portion.[2] For example, if the client asked for a part of the file that lies beyond the end of the file.
417 Expectation Failed
    The server cannot meet the requirements of the Expect request-header field.[2]
418 I'm a teapot
    This code was defined in 1998 as one of the traditional IETF April Fools' jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers.
422 Unprocessable Entity (WebDAV) (RFC 4918)
    The request was well-formed but was unable to be followed due to semantic errors.[6]
423 Locked (WebDAV) (RFC 4918)
    The resource that is being accessed is locked[6].
424 Failed Dependency (WebDAV) (RFC 4918)
    The request failed due to failure of a previous request (e.g. a PROPPATCH).[6]
425 Unordered Collection (RFC 3648)
    Defined in drafts of "WebDAV Advanced Collections Protocol",[11] but not present in "Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol".[12]
426 Upgrade Required (RFC 2817)
    The client should switch to a different protocol such as TLS/1.0.[13]
444 No Response
    An Nginx HTTP server extension. The server returns no information to the client and closes the connection (useful as a deterrent for malware).
449 Retry With
    A Microsoft extension. The request should be retried after performing the appropriate action.[14]
450 Blocked by Windows Parental Controls
    A Microsoft extension. This error is given when Windows Parental Controls are turned on and are blocking access to the given webpage.[15]
499 Client Closed Request
    An Nginx HTTP server extension. This code is introduced to log the case when the connection is closed by client while HTTP server is processing its request, making server unable to send the HTTP header back.[16]

5xx Server Error

The server failed to fulfill an apparently valid request.[2]

Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and indicate whether it is a temporary or permanent condition. Likewise, user agents should display any included entity to the user. These response codes are applicable to any request method.

500 Internal Server Error
    A generic error message, given when no more specific message is suitable.[2]
501 Not Implemented
    The server either does not recognise the request method, or it lacks the ability to fulfill the request.[2]
502 Bad Gateway
    The server was acting as a gateway or proxy and received an invalid response from the upstream server.[2]
503 Service Unavailable
    The server is currently unavailable (because it is overloaded or down for maintenance).[2] Generally, this is a temporary state.
504 Gateway Timeout
    The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.[2]
505 HTTP Version Not Supported
    The server does not support the HTTP protocol version used in the request.[2]
506 Variant Also Negotiates (RFC 2295)
    Transparent content negotiation for the request results in a circular reference.[17]
507 Insufficient Storage (WebDAV) (RFC 4918)[6]
509 Bandwidth Limit Exceeded (Apache bw/limited extension)
    This status code, while used by many servers, is not specified in any RFCs.
510 Not Extended (RFC 2774)
    Further extensions to the request are required for the server to fulfill it.[18]