Assembla.com - великолепный сервис для управления проектами. Пожалуй лучшее, что я пока видел. Обидно только то, что популярность к этому ресурсу пришла гораздо быстрее, чем сам ресурс дорос до этого с технической точки зрения. Как результат, первым делом было сокращено место на сервере под проект с 500 до 200 мб, теперь вот чуть ли не каждый день на сервере ведутся работы, и по полдня нельзя на сайт зайти.
Из жизненных наблюдений. Когда на рынок выходит новый продукт, он зачастую великолепного качества (взять к примеру сгущенку:) ). Через некоторое время, появляется куча дешевых подделок, и самое обидное, что и сам производитель перестает уделять должное внимание качеству.
Однако конкуренция в IT существенно превышает конкуренцию во многих других сферах, так что думаю, что за качеством все равно следить по большому счету нужно, хотя реалии таковы, что зачастую потребителю побыстренькому кидается сырая версия, чтобы опередить конкурентов. А дальше как повезет:)
Вспомнил фильм "Пираты Силиконовой Долины". Там в конце фильма Джобс говорит Гейтсу:
- Бил наш Макинтош лучше Вашего Виндоуз
- Ты так и не понял, Стив? Это уже не имеет ни какого значения...
P.S. ЗЫ сейчас проверю ассемблу, авось уже починили, и я наконец смогу прочитать тикет:)
пятница, 17 октября 2008 г.
четверг, 2 октября 2008 г.
Public – protected – private
Мой друг Паша на днях изложил свои мысли по поводу возможности разделения функций привычных всем модификаторов доступа еще и "модификаторами наследования"... Собственно размышления носят сугубо теоретический характер и я точно не могу судить, на сколько подобная возможность была бы востребована на практике, но сама идея кажется интересной. Собственно вот оригинал статьи:
Public – protected – private.
В последнее время стал замечать, что что-то не так в этой троице. Вроде как все просто – public это модификатор доступа, указывающий, что к элементу можно получить доступ извне, private – только другим членам этого же класса, а protected – этого же класса и производных от него. Но ведь это не так!
То есть вроде и так, но не так. Ведь если вспоминать про производные классы, то можно сказать что помеченный словом public – это наследуемый член, private – не наследуемый, а protected – снова же наследуемый.
То есть получается, что эти три модификатора – это не только модификаторы “доступа”, а еще и модификаторы “наследования” одновременно. Где
Разумно было бы разделить понятия модификаторов доступа и модификаторов наследования, оставив для доступа public и private, и выделив для наследования, например, inherited и non-inherited. Тогда получим еще и четвертую комбинацию – public + non-inherited.
Многие могут сказать, что такая комбинация не нужна, но как известно применение может быть найдено всему чему угодно :) Например, вспомогательный открытый метод, который не пригодиться в производных классах. Кроме того явное использование модификаторов наследования позволит не раздувать производные классы, что в какой-то мере реабилитирует “повторное использование кода” при наследовании.
Конечно, можно предположить, что возникнут проблемы с вызовами виртуальных функций, которые есть в базовом классе, но нет в производном. Почему бы не вызывать как виртуальные только те методы, которые класс реализует от наследуемого интерфейса, так сказать подписывает контракт на реализацию. Такой метод будет гарантировать, что все нужные методы (т.е. те которые указаны в интерфейсе) всегда будут и в производных классах.
Public – protected – private.
В последнее время стал замечать, что что-то не так в этой троице. Вроде как все просто – public это модификатор доступа, указывающий, что к элементу можно получить доступ извне, private – только другим членам этого же класса, а protected – этого же класса и производных от него. Но ведь это не так!
То есть вроде и так, но не так. Ведь если вспоминать про производные классы, то можно сказать что помеченный словом public – это наследуемый член, private – не наследуемый, а protected – снова же наследуемый.
То есть получается, что эти три модификатора – это не только модификаторы “доступа”, а еще и модификаторы “наследования” одновременно. Где
| Доступ | Наследование | |
| Public | Public | Inherited |
| Private | Private | Non-inherited |
| Protected | Private | Inherited |
Разумно было бы разделить понятия модификаторов доступа и модификаторов наследования, оставив для доступа public и private, и выделив для наследования, например, inherited и non-inherited. Тогда получим еще и четвертую комбинацию – public + non-inherited.
Многие могут сказать, что такая комбинация не нужна, но как известно применение может быть найдено всему чему угодно :) Например, вспомогательный открытый метод, который не пригодиться в производных классах. Кроме того явное использование модификаторов наследования позволит не раздувать производные классы, что в какой-то мере реабилитирует “повторное использование кода” при наследовании.
Конечно, можно предположить, что возникнут проблемы с вызовами виртуальных функций, которые есть в базовом классе, но нет в производном. Почему бы не вызывать как виртуальные только те методы, которые класс реализует от наследуемого интерфейса, так сказать подписывает контракт на реализацию. Такой метод будет гарантировать, что все нужные методы (т.е. те которые указаны в интерфейсе) всегда будут и в производных классах.