Come pensare a una pianificazione che preleva da un database come oggetti

Question

Come pensare a una pianificazione che preleva da un database come oggetti

#1 da (1 voti)

5

Sto lavorando su un progetto personale usando Python. Ho utilizzato il controllo di versione al meglio delle mie capacità e se volessi verificarlo ed eseguire l'app link

Se preferisci Floobits, guarda il mio codice attuale in un editor qui: link

Ho imparato il controllo della versione con questo progetto e ho cercato di utilizzare TDD con le mie migliori capacità. Al momento dell'apertura della classe Test_Schedule, è stato difficile scrivere metodi di test.

Una piccola parte di ciò che sto cercando di fare: Sto costruendo un API che gestisce un sistema di pianificazione. Questo comunicherà con il web e con i dispositivi mobili. Gli utenti eseguono l'accesso e possono controllare il loro programma, cambiare le date per visualizzare altri orari programmati e anche selezionare la quantità di informazioni visualizzate (ad esempio mostrare solo server o personale di cucina, vista giornaliera, vista mese, vista calendario).

Quindi ecco la domanda: Come si costruisce un oggetto di pianificazione? Come dovrei visualizzare questo? Quali tipi di domande dovrei chiedermi per aiutarmi ad andare avanti? Sembra che ho bisogno di informazioni utente da entrambi gli utenti e spostare per popolare il programma.

In questo momento sono bloccato. E questo perché ho due oggetti: User e Shift. Ora penso che dovrei creare un oggetto di pianificazione.

un utente contiene _id (user_id), nome, email ....

uno Shift contiene _id, user_id, start_time, stop_time

Per visualizzare questa roba sul front-end, ho bisogno di compilare un programma. Un po 'come questo:

#         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

Questo è solo un esempio, ma dall'aspetto di questo, potrei aver bisogno di Schedule per restituire qualcosa di simile a questo (Maiusc, Nessuno, Maiusc, Maiusc, Nessuno, Maiusc)

Questo è alcuni casi di test nel mio oggetto shift

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):

Ecco il mio processo di pensiero finora:

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)

Questo è il modo più attuale per pensare. Un programma è solo una riga, quindi fondamentalmente un utente. Il programma ha turni e un utente. Più pianificazioni vengono caricate per popolare tutti i dipendenti. Forse Schedule non è il nome migliore, ma non ne sono ancora sicuro.

object-oriented tdd unit-testing python flask

posta Michael Bruce 21.02.2016 - 17:20

fonte

1 risposta

Leggi altre domande sui tag object-oriented tdd unit-testing python flask

Come posso organizzare la mia struttura TFS in modo tale che un progetto one-off che estrae i file da un altro progetto possa essere facilmente gestito? Salva due oggetti di dominio diversi in una chiamata di servizio

score 1 · Answer 1

Ecco la mia idea:

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})

In sostanza, un utente è semplicemente un utente e un turno è semplicemente una definizione di ore di inizio e di fine. La Pianificazione è la parte più interessante: è composta da più date possibili e ogni data può avere più utenti, ciascun utente è collegato al relativo turno in quella data.

Come altri hanno già detto, in generale si vuole sentire e lavorare sul software fino a quando nulla è troppo accoppiato. La presentazione (stampa) non ha molto a che fare con i dati e gli ID non devono essere pensati fino a quando non inizi a pensare al database.

Quando cerchi di capire il modello di dominio, in genere è consigliabile ignorare gli altri componenti del software per quel momento. Quando hai un'idea più strong di ciò che stai cercando di fare, allora puoi iniziare a pensare al resto. Proprio come gli oggetti e le funzioni non dovrebbero essere troppo accoppiati, quindi non devono essere le nostre idee su di loro.