jcmvbkbc: насчет определения методов для всех сотрудников в абстрактном классе. Подумалось, что возможно это не самый лучший вариант. Получается, что employee будет содержать все методы необходимые только для manager. Это разве не приводит к избыточности? Или это нормальная практика и иерархию классов нужно сделать следующим образом (кстати, Person переименовал в Worker):
class Employee: public Worker {}
class Manager: public Employee {}
Или лучше будет всё же воспользоваться приведением типов и не переносить все методы из класса в класс?
почему было не посмотреть чуть шире, и не сказать, что любой сотрудник в первую очередь -- материальное тело, коллекция атомов?
Тогда, чтобы не ошибиться назову базовый класс просто Energy ;)
Благодарю за отклик.
Класс Person я планировал использовать как абстрактный, содержащий все самые базовые поля и методы которые по определению должны быть у любого сотрудника. Правильно ли я понял вашу мысль, что класс Person можно использовать как интерфейс, в котором определены методы для сотрудников всех типов, а реализацию делегировать производным классам? Такое архитектурное решение не будет выходить за рамки главных принципов ООП?
Насчет приведения типов есть мнение, что обычно это не очень хорошо и лучше всего пересмотреть архитектурное решение. Потому и не стал прибегать к этому способу.
P.S. Согласен по поводу не самого удачного названия метода getListEmployee(), признаться, его выбрал на скорую руку. А чем не понравилось название класса Person? Любой сотрудник ведь в первую очередь человек, персона, индивид.
Спасибо за советы.
Задача выяснить +/- фреймворков не стоит, хотя конечно же, было бы полезно. Главная задача поднять сайт с необходимым функционалом и постепенно его развивать. Причем важны 2 нюанса: скорость разработки и постепенное (растянутое во времени) допиливание новых фич. Понимаю, что это противоречит моему желанию взяться за ES6, и писать модульное приложение почти с нуля. Просто, впечатлили новые возможности и захотелось использовать их в долгосрочной перспективе.
Думаю воспользоваться вашим советом по поводу ember.js.
Скорее классический сайт, чем полноценное SPA. Но именно клиентсайд хотелось бы сделать модульным, используя ES6. Отсюда и вытекает проблема. Как организовать весь этот зоопарк технологий и взаимодействие с сервером. Взять, как посоветовали выше, концепцию "толстый/тонкий клиент" или сделать гибрид обычного сайта с модульной архитектурой на клиенте.
VZVZ: Нужды достаточно тривиальны: создание списков, сохранение интересных материалов, муз.плеер со своим функционалом, некий агрегатор соц.сервисов и т.п.
Спасибо.
Вообще, в перспективе видится адаптация сайта под моб.платформы. Исходя из этого, мне больше подойдет вариант с толстым клиентом. Но вопрос "что выбрать для фронтенда?" всё же остаётся. Использовать ангуляр не хочется, т.к. версия 1.5 постепенно уходит в историю, а 2.0 еще сыровата. С другими фреймворками не знаком. Но дело не в том, что нет желания изучить какой-нибудь, а в том, что хочется приобщиться к ES6(2015) и постепенно создавать модульное приложение на клиентсайде.
FinderOT: нет, в данном случае, производительность не имеет большого значения. Указание контекста является удобным и лаконичным способом взаимодействия с элементами, но содержит минус в виде невозможности указать поиск только прямых потомков.
FinderOT: понял Вас, но я хочу узнать, есть ли такой способ, который пропустит фазу "отобрать всех потомков", даже если они только прямые, а будет искать сразу необходимый элемент, к тому же, с указанием контекста.
Да, этот способ тоже верный, но его минус в том, что сначала он отберет весь список, а затем отфильтрует его. Мне нужно, чтобы сразу происходил поиск необходимого элемента.
Теоретически, подойдет, но если не ошибаюсь, то в данном случае, сначала будут отобраны все div.item и только потом будет взят элемент с определенным индексом. Как результат - накладные расходы. =)
К сожалению, не помогло. Функция возвращает странно форматированный массив с корневой директорией:
Array
(
[0] => 07-07-14 04:48PM
134.255.229.133_28000
)
Т.е., даже при указании - ftp_rawlist($h, '-1l /134.255.229.133_28000');
Или лучше будет всё же воспользоваться приведением типов и не переносить все методы из класса в класс?
Тогда, чтобы не ошибиться назову базовый класс просто Energy ;)