Jackfy

Много ответов есть уже, лучше попробую идти рядом с вашими словами. Итак,
> Зачем мне создавать файл, контролирующий это, если я и сам могу контролировать то, какие методы у меня есть
Вы - это ваша голова, вы человек, не робот, ваш может не быть на работе например, или вы сами можете забыть, как у вас взаимодействуют части системы. Интерфейсы - это в общем-то тоже документация. И не нужно строго различать "чисто интерфейсы", и интерфейсы класса - те методы, которые у класса паблик - это точно такой же интерфейс, только он явно не отделен от класса. Когда у класса всего 3-4 метода, и все они связаны простой идеей, то и выделять ничего не надо. Когда у класса уже 10 методов, и среди них есть небольшие смысловые группы, то уже имеет смысл эти группы подчеркнуть. И, в конце концов, вместо каши из 10 методов, вы читаете следующее: class Graph : IEnumerable, IIndexable, IDrawable - и вы знаете, что ваш граф перечисляется, индексируется и рисуется. Это уже очень много информации, вы уже понимаете, как взаимодействуют части вашей системы.

> Может создано это для работы в больших коллективах? Но ведь тогда любой участник сможет поправить и интерфейс.
Да, совершенно верно, для больших коллективов. Нет, участник просто так не сможет поправить интерфейс, не побеседовав с остальными. В лучшем случае участнику придется поправить весь код, который "висит" на этом интерфейсе, в худшем - он в принципе ничего не сможет поменять, если интерфейс "публичный" и используется несколькими командами разработчиков. Классический пример - системы плагинов. Если к MS Word-у уже написано куча плагинов, то MS не может взять и просто так поменять ифейсы, не поломав совместимость. Хотя некоторые аспекты реализации - может. Потому что, как уже сказали выше, интерфейс - это ДОГОВОР. Чем БОЛЕЕ он стабилен, тем ЛУЧШЕ. Команды договариваются (!), создавая интерфейсы, чтобы потом было как можно МЕНЬШЕ конфликтов и разногласий, т.к. проблемы с интерфейсом затрагивают всех. Найдите любую команду от 30 человек, и вы увидите, насколько это все важно.

Еще две вещи напоследок:
1) интерфейсы из ОО языков лишь частный пример понятие интерфейса в жизни вообще. Вы же, когда покупаете SATA-диск, наверное рассчитываете, что сможете его подключить к своему компу? А с чего вы взяли? А, ну конечно, ведь на упаковке написано SATA - значит производитель соблюдает ДОГОВОР - интерфейс передачи данных;
2) необходимость в некоторых фичах языков сложно осознать в личных проектах и даже в маленьких командах. Это тоже как в жизни: свой дом, как говорится, должен построить каждый мужик, а чтобы построить бизнес-центр или высотку, нужны определенные знания, т.к. другие масштабы. Это нормально. Тем не менее, нужно читать и искать примеры. Хотя современные ОО-языки и сами дают много примеров. Раз у вас PHP, почитайте про Iterator например.

Предположим, что с будущей функциональностью Вы определились. Тогда Вы точно знаете, кто или что будет поставлять данные, и кто/что будет их потреблять.

Теперь выясните, кто будет обращаться к вашей системе, чтобы передать или забрать данные, а к чему будет обращаться Ваша программа. Те системы или пользователи, которые обращаются к программе сами, нарисуйте схематически на листе бумаги вверху. Те, к которым будет обращаться программа (включая БД), - снизу.

Теперь нарисуйте под каждым нарисованным сверху субъектом прямоугольник с названием UI или API - это интерфейсы, к которым будет обращаться пользователь или внешняя управляющая система. Иногда UI тоже может обращаться к API. Объедините все прямоугольники с UI одним контуром и обзовите слоем UI. Объедините все прямоугольники с API и обзовите слоем сервисов.

Для систем, нарисованных снизу, укажите компоненты, которые будут отвечать за доступ к этим системам. Объедините все эти компоненты одним контуром и обзовите слоем доступа к данным.

Между слоем сервисов и слоем доступа к данным нарисуйте большой контур и назовите его слоем бизнес-логики. В маленьких прямоугольниках внутри этого контура перечислите основные бизнес-задачи. Один компонент Вашей системы будет решать одну бизнес-задачу.

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

Получите логическую архитектуру. Разбросайте слои по серверам - получите физическую архитектуру.

А дальше - детально прорабатывайте каждый маленький квадратик. Всё.

Я постараюсь подключить философию, примеры и "как если бы я говорил в баре с вами".

ЯП - это инструмент. Инструмент всегда взаимодействует с объектом и со средой. Соответственно, вам точно нужно что-то знать про объект и уметь пользоваться инструментом внутри среды, а это потащит дополнительные знания, назовем их "естественными" зависимостями. Насколько глубоко их нужно знать? Тут ответа не бывает: настолько, насколько нужно и хочется. Тут важен баланс и акцент. Если нет строгих параметров на уровне разума, нужно верить интуиции, потому что больше нечему. Для JS-программиста JSON/jQuery/AJAX - это естественные зависимости, их в любом случае не получится обойти. Даю зуб, что вам хватит вечера и немного гугла, чтобы стать чуть ли не LIKE A PRO в этом. Это все форматы хранения данных, либы, парадигмы. Это примерно как прочитать состав у шоколадки по сложности и входному порогу. Скорее всего, вас пугают сложные слова. Примерно как сказать "НАПРАВЛЕННЫЙ АЦИКЛИЧЕСКИЙ ГРАФ", и вы сразу знаете теорию графов, хотя с практической точки зрения суть настолько элементарна, что аж страшно, а вы будете долго прокрастинировать и искать что попроще.

Это что касается близких и неизбежных естественных зависимостей. Но есть и более далекие, но тем не менее все равно естественные, их знание позволяет развиваться, иметь более полную картину в голове. Вот есть гитарист, он может быть просто технарем. Есть гитарист-музыкант, который чувствует дорийский лад в блюзе. А есть гитарист-музыкант-звукорежиссер, который наконец-то понял, как надо жирно сводить гитары и теперь в симбиозе со звукарем. Кто из них самый крутой, очевидно.

Вы можете просто верстать (html/css) и игнорировать программирование в целом. Но естественная среда противится: вы уже (!) пишете на декларативном языке, неплохо было бы узнать об этом подробнее (о языках или даже о типизации), тем более, что крайне близко к вам находится интереснейший язык js, а там моментально вылезут проблемы связывания html и js, разные подходы к этому, целые парадигмы и фреймворки; и вот вам выпадает интересная задача по анимированию svg, вы курите мануал по нужной либе, читаете что-то про reflow/repaint, внезапно узнаете что-нибудь про селекторы. И через какое-то время, будучи все тем же верстальщиком, вы видите архитектурный косяк дизайна, который очень неудобно укладывается в используемые технологии, предлагаете его пофиксить и спасаете команду от факапа через месяц, когда какой-нибудь транзишн наложится на какой-нибудь position: fixed и еще и в Safari упадет анимация и только там, а тут и новая тудушка: "Переделать, нафиг, всю шапку, чтобы ок было". Что-то изменилось в мышлении и картина стала полнее. ВНЕЗАПНО вы уже и инженер, можно сказать, ЗП растет, все дела, рутины меньше стало.

Так вот, о инженерах. Можно выучить, например, Python за пару дней, там же отличный мануал. Но настоящий программист - это инженер, потому что вся суть в архитектуре, во взаимодействии объектов/компонентов и в том, как все это соотносится с задачей. Какой молоток взять, это уже без разницы, как состав на банке прочитать. То есть суть вашей работы заключается как раз в объекте и среде, а не в инструменте. Образно говоря, когда вы сидите в кафе, суть не в чашке чая, а в атмосфере и как вы себя в ней чувствуете, но при этом чашка чая нужна, чтобы заставить вас что-то делать и вписать тем в самым во взаимодействие со средой, поэтому придется научиться красиво пить чай.

Подведу тут черту: естественные зависимости - это норма, а суть в инжиниринге. Можно двигаться по зависимостям дальше. У вас есть интервал, где есть минимальный порог, ниже которого нельзя, и максимальный, где вы "мастер на все руки", что тоже плохо. Между минимальным и максимальным порогом можно двигаться. Взять те же сети: разворачиваете приложение, видите линуху, настраиваете сеть. Можно немного заморочиться и прочитать про основы маршрутизации, буквально 2 вечера, можно еще про сетевой стек в линукс, еще 2 вечера, и уже будет во много раз проще. Кроме того, возрастет культура в целом и если вы программист на бэке, то вам будет проще взаимодействовать с админами. Про OSPF, очевидно, читать не надо, важен баланс. Баланс - это понимание того, на что у вас акцент (вы программист? какой? фронт/бэк? насколько важны сети/ос? проектируете бд? верстаете? интересен ли прикладной кодинг под какую-то ос и так далее...) и насколько интересны естественные далекие зависимости выбранной области.

Так вот, теперь у нас есть естественные зависимости, инжиниринг и баланс между порогами. А не php/jquery/html/css.

Важно также отметить, что все очень быстро развивается сейчас, а это еще один аргумент, что привязываться к инструменту не стоит. Кто-то может сказать, мол, взять тот же js, программирование на нем - это целая парадигма, иной подход, свои фичи. Это так, но дело тут не в js, а в целом в динамичных/интерпретируемых языках.

Кстати, что касается SEO: с технической точки зрения это пара мануалов от гугла и не более того. Там сеошники наговорить могут много, с ними надо быть осторожнее :)

А теперь, собственно, выводы:

1) Вакансий крутых много, надо пробовать. Нужно только отличать близкие и необходимые естественные зависимости от мастера на все руки. Я считаю, что мастером на все руки нужно поработать хоть однажды, чтобы просто понять, почему это плохо. Но зависимости будут всегда, и это норма. Вы перечислили слишком радикально, конечно.
2) Себя пилить под вакансию не нужно. Нужно просто идти туда, где интересно, всегда стараться быть инженером и не убить в себе искусство (то есть не бояться делать так, как кажется правильно, чтобы либо убедиться в правоте, либо ошибиться и стать круче).
3) Не нужно думать в стиле "а что если завтра рубионреилс развалится, комьюнити разойдется, вакансий не будет, что я буду делать". Вы же инженер. У вас опыт в проектировании IT-систем, перейти на что-то смежное, если будет понятно, что технология умирает, не составит труда.
4) По естественным зависимостям нужно двигаться по мере интереса, вы станете от этого только лучше.

Это, конечно, если вам действительно все это интересно. Все это области, очень близкие к искусству, и тут надо любить все это делать.

В общем, с дипломами вот какая штука.

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

Yet another framework - это не улучшение (вряд ли Вы напишете что-то лучше существующих решений).

А вот, к примеру, что-то типа "особенности поведения пользователей в условиях..." - уже ближе.
Грубо говоря, некое исследование, основанное на карте кликов и прочих вебвизорах.
Чего уж там, даже данные по поведению игроков во время чумы в WoW (недавно была статья на хабре) - это больше похоже на диплом, чем написание очередного фреймворка.

Иными словами - сначала наука, потом техническая реализация (которая ВАКу будет неинтересна).

Конкретную тему пока не могу предложить, уточните кафедру, лабораторию и чем занимаетесь вообще.

1. Руби не поддерживает методы с разными сигнатурами. Но вместо ошибки он просто принимает последнюю вычисленную. В вашем случае первый метод init затрётся вторым. Для примера поменяйте их местами и вызов A.new(1) вернёт ошибку о недостаточности аргументов.
Корни этой проблемы тянутся из динамичности руби и отсутствия pattern matching.

2. initialize нельзя назвать конструктором, потому что конструктором фактически является метод класса new. И вот в A.new всегда вызывается метод инстанса initialize, если он присутствует. Но это настолько незначительное замечание, что можно и initialize называть конструктором, ошибка на данном этапе не существена.

По поводу нескольких конструкторов - вот вам шаблон:

def initialize(*args)
  if args.length == 1
    #initialize method 1
  else
    #initialize method 2
  end
end