Feel Good.

24 сентября 2010

Шаблон реализации Equals

Работая с объектами, нам часто явно или неявно приходится их сравнивать их друг с другом. За сравнение объектов отвечает метод Equals или его типизированная версия из IEquatable, возвращающая true в случае если объекты равны, в противном случае false. Стандартная реализация метода Equals не всегда удовлетворяет потребностям разработчика, так как она не учитывает конкретных особенностей объекта, и в этом случае, реализация конкретного Equals/IEquatable ложится на плечи самого разработчика. Каждый разработчик вправе по-своему реализовать данную функциональность (не нарушая правил Implementing the Equals Method), как ему будет удобно. У меня, как у разработчика, на этот счет со временем выработался удобный шаблон реализации метода Equals/IEquatable, состоящий из 2-х простых правил:
  1. От простого к сложному: выполнять сравнение начиная с простых условий и заканчивая более сложными.
  2. Понять равенство/неравенство объектов как можно раньше: делайте незамедлительный "return true/false".

31 августа 2010

Enum поле в XML API

Проектируя публичное API очень важно понимать, что Ваше API будут использовать другие разработчики различного уровня, которые будут вынуждены разбираться в нем с нуля. Именно поэтому важную роль здесь играет простота и понятность созданного Вами API. Интуитивно-понятное API намного проще осваивать, и тем более использовать. Любое API подразумевает обмен сообщениями между "клиентом" и "сервером", и зачастую такие сообщения удобно записывать в виде XML. Стандартная ситуация, Вы формируете некий XML и посылаете его на сервер, сервер разбирает его и отвечает Вам другим XML (XML API). К примеру, это может быть запрос аутентификации:

<request>

    <auth>

        <login>ilya</login>

        <password>*****</password>

    </auth>

</request>


и соответственно ответ на запрос со стороны сервера будет выглядеть следующим образом:

<response>

    <result>42</result>

 

    <!-- Остальные поля ответа... -->

</response>


05 августа 2010

Marker Interface против Custom attributes

Бывают случаи, когда у разработчика C# возникает острая необходимость пометить некую сущность маркером (Marker), и в зависимости от типа маркера соответственно обрабатывать сущность. Например, Вы получаете сообщения, и для различных типов сообщений (но не для всех, а например только для типа MessageB) делаете запись в лог о их получении (например, в методе OnReceive(Message msg)):

class Message{}

class MessageA : Message { }

class MessageB : Message { }

class MessageC : Message { }