- От простого к сложному: выполнять сравнение начиная с простых условий и заканчивая более сложными.
- Понять равенство/неравенство объектов как можно раньше: делайте незамедлительный "return true/false".
Feel Good.
24 сентября 2010
Шаблон реализации Equals
Работая с объектами, нам часто явно или неявно приходится их сравнивать их друг с другом. За сравнение объектов отвечает метод Equals или его типизированная версия из IEquatable, возвращающая true в случае если объекты равны, в противном случае false. Стандартная реализация метода Equals не всегда удовлетворяет потребностям разработчика, так как она не учитывает конкретных особенностей объекта, и в этом случае, реализация конкретного Equals/IEquatable ложится на плечи самого разработчика. Каждый разработчик вправе по-своему реализовать данную функциональность (не нарушая правил Implementing the Equals Method), как ему будет удобно. У меня, как у разработчика, на этот счет со временем выработался удобный шаблон реализации метода Equals/IEquatable, состоящий из 2-х простых правил:
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 { }
Подписаться на:
Сообщения (Atom)