Violet Tape » Newbie

PostSharp. Overview.

Koissakh Kadderah — Thu, 15 Apr 2010 04:26:39 +0000

Before turning directly to the theme of the story, it is necessary to say a few words about the system things.

Aspect-Oriented Programming

Aspect-oriented programming (AOP) - programming paradigm, based on the idea of separation of functionality to improve the partitioning the program into modules.

There are many classes of problems whose solution is impossible in the context of the OOP, or lead to a large rubbish code and connectivity modules that bad. For example, logging. In order to keep a log of the program, it is necessary in each service method of placing multiple lines of service call logging, as it may have to pass through the input parameters of methods. All this code would not apply to the implementation of real-world task entrusted to the method, but only an eyesore. Besides, how many extra lines of code have to write by hand!

Another example is the authentication and verification of access rights. In good, before the execution of important methods, one must each time test whether the current user rights to run the specified method. Here, too, can be a lot of hassle and code

In general, any cross-cutting code drops out of the opportunities the PLO. AOP programming, by contrast, provides all the tools to highlight "through the code in separate entities, which significantly simplifies the code for testing and for use.

(...)
Read the rest of PostSharp. Overview. (1,417 words)

Feed enhanced by Better Feed from Ozh

Design pattern “Specification”

Koissakh Kadderah — Tue, 13 Apr 2010 04:00:52 +0000

Disclaimer

This article is mostly for beginners at programming, who know only some programming patterns or don’t know them at all.

About design patterns

Let’s take definition of design pattern from Wikipedia.

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

For instance we can imagine that we are accomplishing a task “by analogy”. Or, for example, solving the same equation, but with another concrete numbers.

Pattern “Specification”- is a pattern of supplement’s conduct. The result of the implementation will be a Boolean variable; giving you the input of the operator of conditional transfer you control the behavior of the program.

With the help of the following techniques you can:

Make your code more readable and concise
Avoid duplications of code
Easier to make changes to the implementation

As always, the work of the complex mechanism better shows a concrete example. Let's start with simple things, gradually moving to the complex. I will try to avoid situations in which revealed only a simple example, but as it is applied in real life – unclear.

(...)
Read the rest of Design pattern “Specification” (1,621 words)

Feed enhanced by Better Feed from Ozh

DDD & TDD. Part III

Koissakh Kadderah — Wed, 03 Feb 2010 18:02:17 +0000

As the result of previous parts we have domain with core classes and services. Actually we can generate and process any amount of data with methods provided by domain services. But there are some issues:

How user will input data;
How data will reconstitute/persist.

Domain by nature and the general plan must be absolutely independent and free from technology aspects as GUI/user interaction (WPF, WinForms, Web) and the data layer implementation (MSSQL, MySQL, Oracle, etc.)

Layers

Step by step we realize that application should be multi layered. And there are minimum possible set of layers, as I see it:

Domain –business logic layer. In this layer described HOW to work with data.
Data layer. At this level implemented saving and recovering data to/from external data storage to domain objects. Extracting these actions in separate layer makes application more agile, i.e. it’s easy to deal with several different DB without changing other parts of the application.
Presentation layer. Here we say WHAT to do with data: define specific sequence of domain services and return calculated result to GUI. So, this layer connects Domain and Front End.
User Interface (Front End). This level can be console, win forms, web, even mental transmission to mind! =) Try to keep this layer as dumb as possible. No data changes, no application flow logic – only do what other says with any initiative.

Now when we know layers responsibilities, next goal is to understand how they interconnect with each other.

(...)
Read the rest of DDD & TDD. Part III (836 words)

Feed enhanced by Better Feed from Ozh

DDD & TDD. part II

Koissakh Kadderah — Sat, 30 Jan 2010 18:00:49 +0000

Disposition

So we have domain classes with minimal set of properties and methods. Also we have several tests on these classes. The goal is to learn how deal with domain classes – i.e. write services which will do complex calculations and modifications. For example count students in selected course.

Domain services

Assume that one of the tasks is count classes for selected course and how many students in them.

Let’s think which domain classes known about each other:

“School” knows how many “Class”es it contains.
“Class” knows how many students it contains.

I think it will be enough for now. What is the easiest way that will implement most of novice? Add to “School” method:

public int CountStudent(int classNumber) { … }

But it is a bad idea because of next reasons:

It leads to growing responsibilities of “School” class and the result is coupling;
Became harder to maintain and change “School”;
Also can appear issues for test writing.

(...)
Read the rest of DDD & TDD. part II (1,366 words)

Feed enhanced by Better Feed from Ozh

DDD & TDD. part I

Koissakh Kadderah — Tue, 26 Jan 2010 03:00:27 +0000

Disclaimer

Article is a simple presentation of DDD and TDD in order to show how to deal with it and give an opportunity to start development according describing techniques. Those who already practice TDD and DDD, please don’t be strict to words.

Magic abbreviations

DDD – Domain Driven Design, in few words it is a solution code manner. And your target is an extract main application logic, the core, in a separate independent module. Domain must be independent from specific technologies, it won’t relay on underlying data, graphical presentation and so on.

TDD – Test Driven Design, developing application by tests. “Test become before code”.

Both of these practices (maybe better to call it philosophy) come together in my projects and, to be honest, for me it’s hard to imagine their usage separately. But yes, you can use them absolutely separate and no one oblige you to apply them in every project together.

There is a dozen of books, articles and other stuff in any format and size. Somewhere it is simpler, somewhere with more complex vision. I wouldn’t like to make a historical excursion how DDD and TDD have been invented, because it’s easy to find out in web, to google Eric Evance books or visit Martin Fowler site. I’d like to share my vision of subject in simple words. Tell how it helps, works, evolves and supports. I hope I can achieve the goal.

Okay, let’s take a closer tour by these techniques.

(...)
Read the rest of DDD & TDD. part I (1,775 words)

Feed enhanced by Better Feed from Ozh