Нравится мне cloud-cuckoo, вот только обновляется редко... Посему решил сам сделать пост по теме

Недавно на кухоньке во время обеда, зашел разговор о Java-задачах. И мне было предложено решить одну из них. Я ее решил, как только сел за ПК, но ответ оказался не рациональным. Мне ни капельки обидно не было за столь тупую ошибку в моем подходе.
На базе той задачи я решил составить новую, чуть более сложную.

Смотрим внутри, чтоб на главной не маячило. 

В этом курсе вы найдете 7 видеоуроков по java. 

УРОК №1

В этом уроке мы с вами напишем первую программу, поймем что такое объект и ООП в Java и немного усложним пример, создадим объект и будем им манипулировать. Для работе в этом уроке вам понадобятся установленные java 1.6 или 1.7 (jdk, не jre, сайт oracle.com) и последняя версия NetBeans (netbeans.org). Все можно скачать с официальных сайтов.

• 1 урок (1 часть) 
• 1 урок (2 часть)

УРОК №2

Сегодня мы с вами пройдем 1 небольшую, но очень полезную тему. 

В прошлом уроке я обещал рассказать про доступы к переменным класса через гетеры и сетеры. 

Зачем они нужны? 

С помощью них мы можем защитить наш объект от неправильного изменения какой то свойства, в результате чего наш объект может сломаться или повести себя не так, как нужно.

• 2 урок (1 часть) 
• 2 урок (2 часть) 
• 2 урок (3 часть) 

Given an array of n integers, find the sum of the most common integer.

Example: (2,4,5,6,4) – return 8 (as 4+4 = 8) .
(1,2,1,3,1) – return 3 (as 1+1+1 = 3).

Вы создали список с помощью

List<String> test = Arrays.asList("a", "b", "c");

Поделали какие-то действия и решили удалить некий элемент из коллекции, скажем первый:

test.remove(0);

И тут внезапно:

Exception in thread "main" java.lang.UnsupportedOperationException at java.util.AbstractList.remove(AbstractList.java:144) at com.ubs.fi.webconsole.TestIterator.main(TestIterator.java:19)

С НОВЫМ ГОДОМ

2012 пришел!! Клауду год! или больше!!!

Год начался неплохо!!

Смотрел я на раздел продаж сайтов на мауле, на пр-су бирже и на форуме ммгп.

Думаю купить что-то путнее с доходом, примрено за косой-другой баксов.

И вижу что за косой продают в основном полный шлак, требующий мног овнимания разбирательств и времени.

Зашел на форум друпал, глянул на цены за создание сайтов с функионалом нужным.

Денег там берут примрено 2к-осых баксов за создание......

Раскрутка и наполнение остается за мной.....

А купить что-то готовое с доходом, мне кажется нереально за такие деньги....

Кстати прикольно подредактировал форму с тэгами, удобно и приятно

П,С, никого не интересует сколько вложен ов сайт, инетерсуют только показалтели))))))

Я сейчас  с этим столкнулся, и вспомнил ка я продавал догфлай))))) ЛОЛОЛО

Синглтон - это просто класс, объект которого создается лишь один раз. Они обычно представляют системный компонент, который является уникальным. Например, менеджер окон или файловая система. 

До релиза java 1.5, существовало два метода реализации синглтонов. Оба метода основывались на закрытом конструкторе и объявлении открытого статического метода для обеспечения доступа к объекту синглтона. В первом случае, объект был final полем класса:

// Singleton with public final field public class Elvis { public static final Elvis INSTANCE = new Elvis(); private Elvis() { ... } public void leaveTheBuilding() { ... } }

Закрытый конструктор вызывается только один раз, для инициализации  публичного открытого поля Elvis.INSTANCE. Отсутствие публичного и защищенного конструкторов гарантирует лишь один объект: Класс Elvis создается единожды - не больше и не меньше. Хотя, есть один большой недостаток такого подхода - клиент с определенными привилегиями  может вызывать закрытый конструктор с использованием рефлексии с помощью метода AccessibleObject.setAccessible. Чтобы защититься от такой угрозы, необходимо модифицировать конструктор таким образом, чтобы он выбрасывал исключение при попытке создать второй экземпляр. 

   Во втором подходе реализации синглтонов, публичным членом является статический фабричный метод:

// Singleton with static factory public class Elvis { private static final Elvis INSTANCE = new Elvis(); private Elvis() { ... } public static Elvis getInstance() { return INSTANCE; } public void leaveTheBuilding() { ... } }

      Статические фабрики и конструкторы имеют общее ограничение: они плохо масштабируются при большом количестве опциональных (необязательных) аргументов.

Рассмотрим случай класса, описывающего состав продукта, который обычно можно найти на любом продукте в магазине. Допустим, на  этикетке продукта обозначены размер (емкость), количество элементов в упаковке, калории в 1 шт. и более двадцати других параметров: жирность, наличие соды и т.д. Большинство продуктов имеют нулевые значения для необязательных полей. Какие типы конструкторов или статических методов Вы бы выбрали для такого класса? Традиционно, программисты использовали шаблон "Телескопического конструктора". Суть его в следующем :в одном конструкторе  вы описываете в конструкторе только необходимые параметры, в другом - необходимые + 1 необязательный; в третьем - необходимые + 2 необязательных и т.д. В итоге, класс превращается в конструкторного монстра. 

Вот как это выглядит на практике:

    Стандартным способом создания объектов класса является использование открытых (public) конструкторов. Однако, существует и другая техника, которую должен знать каждый разработчик.

Класс может объявить статический фабричный метод (static factory method), который будет возвращать объект класса.

    В качестве простого примера можно рассмотреть класс Boolean (враппер над примитивом boolean). Этот метод транслирует boolean в ссылку на объект Boolean:

public static Boolean valueOf(boolean b) { return b ? Boolean.TRUE : Boolean.FALSE; }

Статические фабричные методы имеют свои преимущества и недостатки.

Первым преимуществом является наличие имен у методов.

Если параметры конструктора не описывают объект, который возвращают, то статический метод с хорошо подобранным именем будет более читабелен. Класс может иметь только один конструктор

с данной сигнатурой. Программисты часто обходят это ограничение путем объявления двух конструкторов с одинаковым набором аргументов, но с различным порядком. Но это, на самом деле, очень

плохой подход. Пользователь такого API никогда не запомнит какой конструктор следует использовать в данной ситуации, а также может вызвать неподходящий конструктор по ошибке. При работе

с таким классом придется часто обращаться к документации (если конечно она существует).