Como pensar em um cronograma que extrai de um banco de dados como objetos

5

Estou trabalhando em um projeto pessoal usando o Python. Eu tenho usado o controle de versão para o melhor de minhas habilidades e se você gostaria de verificá-lo e executar o aplicativo link

Se você preferir o Floobits, veja meu código atual em um editor aqui: link

Eu tenho aprendido controle de versão com este projeto e tenho tentado usar o TDD com o melhor de minhas habilidades. Atualmente abrindo a classe Test_Schedule, tem sido difícil escrever métodos de teste.

Uma pequena fatia do que estou tentando fazer: Eu estou construindo uma API que lida com um sistema de agendamento. Isto irá se comunicar com a web, bem como dispositivos móveis. Os usuários fazem login e podem verificar sua agenda, alterar datas para ver outros horários programados e também escolher a quantidade de informações exibidas (isto é, mostrar apenas servidores ou equipe da cozinha, exibição diária, exibição mensal, exibição de calendário).

Então, aqui está a pergunta: Como se construía um objeto de agendamento? Como devo visualizar isso? Que tipos de perguntas devo fazer para me ajudar a avançar? Parece que preciso de informações do usuário do usuário e de mudança para preencher o cronograma.

Agora estou preso. E isso é porque eu tenho dois objetos: User e Shift. Agora estou pensando em fazer um objeto de planejamento.

um usuário contém _id (user_id), nome, email ....

a Shift contém um _id, user_id, start_time, stop_time

Para exibir essas coisas no front end, preciso preencher um cronograma. Mais ou menos assim:

#         mon  tues weds thurs fri  sat  
# user1   4:00 ____ 6:00 4:00  5:00 6:00 
# user2   4:00 5:00 6:00 ____  5:00 6:00

Este é apenas um exemplo, mas pelo que parece, eu preciso que o Schedule retorne algo assim (Shift, None, Shift, Shift, None, Shift)

Isto é alguns casos de teste no meu objeto de turno

def test_create_shift(self):
def test_shift_throws_error_if_time_is_not_int(self):
def test_save_shift_to_database(self):
def test_get_shifts_by_id(self):
def test_get_shifts_within_date_range_by_id(self):   
def test_get_shifts_on_specific_date_by_id(self):
def test_get_shifts_before_end_time_by_id(self):
def test_get_shifts_after_start_time_by_id(self):
def test_get_shifts_exactly_on_start_date_by_id(self):
def test_get_shifts_exactly_on_end_date_by_id(self):
def test_get_current_weeks_shifts_by_id(self):

Aqui está o meu processo de pensamento até agora:

schedule = Schedule(user_id) <---- no range added

test_no_range_added_returns_this_weeks_shifts_for_user()
assertEquals(len(schedule.shifts), 7)

test_user_with_no_shifts_returns_none_for_each_day_in_range()
    for i in range(schedule.shifts):
        assertEqual(schedule.shifts[i], None)

Este é o pensamento mais atual. Um cronograma é apenas uma linha, então basicamente um usuário. Agenda tem turnos e um usuário. Várias agendas são carregadas para preencher todos os funcionários. Talvez o Schedule não seja o melhor nome, mas ainda não tenho certeza.

    
por Michael Bruce 21.02.2016 / 17:20
fonte

1 resposta

1

Aqui está a minha ideia:

class User(object):
   """A user of the scheduling system."""

   def __init__(self, name, email):
      self.name = name
      self.email = email


class Shift(object):
   """
    A user's shift.
    Does not represent an actual date, only the start and end hours.
    """

   def __init__(self, start, end):
      self.start = start
      self.end = end

class Schedule(object):
   """
   A schedule is made out of multiple date objects, linking
   these dates to multiple users, and their shifts.
   """

   def __init__(self):
      self.shifts = {}

   def set_user_shift(self, date, user, shift):
      try:
         self.shifts[date]
      except KeyError:
         self.shifts[date] = []

      self.shifts[date].append({'user': user, 'shift': shift})

Basicamente, um usuário é simplesmente um usuário, e um Shift é simplesmente uma definição de horas de início e término. A programação é a parte mais interessante: é composta de várias datas possíveis e cada data pode ter vários usuários, cada usuário vinculado ao respectivo turno nessa data.

Como outros já disseram, em geral você quer sentir e trabalhar no software até que nada esteja muito acoplado. A apresentação (impressão) realmente não tem muito a ver com os dados, e os IDs não precisam ser pensados até você começar a pensar no banco de dados.

Ao tentar entender o modelo de domínio, geralmente é um bom conselho ignorar os outros componentes do software naquele momento. Quando você tem uma idéia mais strong do que você está tentando fazer, então você pode começar a pensar sobre o resto. Assim como objetos e funções não devem ser muito acoplados, também não devem ser nossas idéias sobre eles.

    
por 01.08.2016 / 09:52
fonte