![[1]](https://svalko.org/data/2008_12_05_23_06_344103_1.gif){kind=link}
http://lex-kravetski.livejournal.com/151185.html
про индейцев и программы...
клюкед
2008-01-23 15:23:02 #
ебануца 0_о
2008-01-23 17:05:40 #
Я на понимаю, какая принципиальная разница и большее удобство в использовании между оператором "водкосалосложение" и сложить(вотка, сало). Объясните, кул-хацкеры?
2008-01-23 17:15:29 #
Имхо сложить(водка, сало) гибче, ибо тогда складывать можно что угодно; а если сложить() будет принимать в качестве аргумента массив, то вообще мега-удобно выходит:
сложить([пефко, колбаско, водка, огурчег, пефко, водка, пефко, водка, колбаско]);
А вот водкасалосложить это даже не процедурный подход, а хуй знает што. По уму тут нужно делать такую штуку:
водка.сало.колбаско.водка.сало.колбаско.сложить;
То есть и объектно-ориентированный подход остается и читаемость повышается и гибкость ниибацо. Но тогда каждый класс все таки должен знать о других каким-то образом. Нарушается изоляция между ними. Плохо.
Итого: лучше бы индейцы мескалито поставляли в достатке, тогда белые программисты сами придумали отличные новые парадигмы "как говорить с кремниевыи идолами"...
сложить([пефко, колбаско, водка, огурчег, пефко, водка, пефко, водка, колбаско]);
А вот водкасалосложить это даже не процедурный подход, а хуй знает што. По уму тут нужно делать такую штуку:
водка.сало.колбаско.водка.сало.колбаско.сложить;
То есть и объектно-ориентированный подход остается и читаемость повышается и гибкость ниибацо. Но тогда каждый класс все таки должен знать о других каким-то образом. Нарушается изоляция между ними. Плохо.
Итого: лучше бы индейцы мескалито поставляли в достатке, тогда белые программисты сами придумали отличные новые парадигмы "как говорить с кремниевыи идолами"...
2008-01-23 17:16:57 #
кстати какого хуя этот пепер и свое хардваре не замутил? из огурцов и свежего гуано например
2008-01-23 19:50:46 #
клюкед, данке. Я тока не понял:
"По уму тут нужно делать такую штуку:
водка.сало.колбаско.водка.сало.колбаско.сложить;
То есть и объектно-ориентированный подход остается и читаемость повышается и гибкость ниибацо."
Про объектно-ориентированный подход понял (вотка там, колбаска - это все нам близко и руками при желании можно поторогать). Про читаемость тоже ясна (всяко лучше читается, чем водкасалоколбасководкасалоколбаскосложить). Я не понял про гибкость. Это как? То, что можно сначала закусить, а потом дернуть? Проясните ситуацию, плз.
И эта... без сильно умных слов. Я ж не программер, ё-моё.
"По уму тут нужно делать такую штуку:
водка.сало.колбаско.водка.сало.колбаско.сложить;
То есть и объектно-ориентированный подход остается и читаемость повышается и гибкость ниибацо."
Про объектно-ориентированный подход понял (вотка там, колбаска - это все нам близко и руками при желании можно поторогать). Про читаемость тоже ясна (всяко лучше читается, чем водкасалоколбасководкасалоколбаскосложить). Я не понял про гибкость. Это как? То, что можно сначала закусить, а потом дернуть? Проясните ситуацию, плз.
И эта... без сильно умных слов. Я ж не программер, ё-моё.
2008-01-23 23:26:03 #
BadMf, конечно, мы ж все люди-человеки.
Каждый класс (водка, сало, колбаско) имеет внутри экземпляры всех остальных классов и может к ним обращаться. Помимо этого, каждый класс имеет и методы (например "сложить", а лучше "принять"). При вызове такого метода он проходит от объекта, из которого был вызван, по всем "хозяевам" "вверх" и выполняет требуемые действия. Может складывать, а может и принимать. И как бы аккумулирует результат. То есть в моем примере
водка.сало.колбаско.водка.сало.колбаско.сложить;
получается так:
1. метод сложить смотрит, что был вызван из колбаски
2. смотрит, кто ее "хозяин" (в данном случае это сало)
3. проходит так до самой первой водки, запоминая все шаги
4. выполняет требуемое дествия со всеми компонентами
Тут правда есть маленькое ебанько - рекурсия. Не совсем понятно, когда должны создаваться экземпляры всех этих классов. Очевидно, что динамически... Кстати, я слышал подобная тема релизована на шаблонах c++ для написания SQL запросов.
В общем, что-то я запизделся 0_о ...
Каждый класс (водка, сало, колбаско) имеет внутри экземпляры всех остальных классов и может к ним обращаться. Помимо этого, каждый класс имеет и методы (например "сложить", а лучше "принять"). При вызове такого метода он проходит от объекта, из которого был вызван, по всем "хозяевам" "вверх" и выполняет требуемые действия. Может складывать, а может и принимать. И как бы аккумулирует результат. То есть в моем примере
водка.сало.колбаско.водка.сало.колбаско.сложить;
получается так:
1. метод сложить смотрит, что был вызван из колбаски
2. смотрит, кто ее "хозяин" (в данном случае это сало)
3. проходит так до самой первой водки, запоминая все шаги
4. выполняет требуемое дествия со всеми компонентами
Тут правда есть маленькое ебанько - рекурсия. Не совсем понятно, когда должны создаваться экземпляры всех этих классов. Очевидно, что динамически... Кстати, я слышал подобная тема релизована на шаблонах c++ для написания SQL запросов.
В общем, что-то я запизделся 0_о ...
2010-01-09 17:07:25 #
Аффтар ваапще прокололся только в одном месте. про уловитель запаха. во все остальное я бы поверил))))
2010-01-09 17:11:59 #
про гибкость означает, что ты можешь не только дерябнуть и закусить, но еще и дунуть, и не только здесь. вобщем очень гибкая система.оСвятойДухКомпьютерСгенериуйФормулуСинтетическийНаркотикНовыйБезопаснеНаОсновеБазЛекарствС\адресБазы\. вобщем, очень гибкая система.